DEBUG_LOCKS_WARN_ON(sem->owner != ((struct task_struct *)(1UL << 0)))

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reproduced on my side. This backtrace only shows one time after boot up unless reboot again.

This backtrace is introduced by KFDIPCTest.BasicTest(other tests also can introduce it).
This test defines some buffers which are mapped to gpu, and the fork later causes this warning. 

The code comments says libhfskmt should do cleanup work after fork as these buffers are invalid in child process.
But the warning shows during fork(), how libhsakmt do such cleanup work?

-----Original Message-----
From: Kuehling, Felix 
Sent: 2018å¹´7æ??13æ?¥ 0:32
To: Michel Dänzer <michel at daenzer.net>; Pan, Xinhui <Xinhui.Pan at amd.com>
Cc: amd-gfx at lists.freedesktop.org
Subject: Re: DEBUG_LOCKS_WARN_ON(sem->owner != ((struct task_struct *)(1UL << 0)))

[+Pan Xinhui]

On 2018-07-12 03:16 AM, Michel Dänzer wrote:
> On 2018-07-12 02:43 AM, Felix Kuehling wrote:
>> Kent just caught a similar backtrace in one of our KFD pre-submission 
>> tests (see below)
> Yeah, looks the same.
>
>
>> Neither KFD nor AMDGPU are implied in the backtrace. Is this a 
>> regression in the kernel itself? amd-kfd-staging is currently based 
>> on 4.18-rc1.
> FWIW, I saw this with 4.17 based kernels already, and I didn't have 
> CONFIG_DEBUG_RWSEMS enabled with older kernels, so I'm not sure it's a
> (recent) regression.

I've now also seen it on Oded's branch (4.17-rc5). It is reproduced reliably by a new test that Pan Xinhui just added to our kfdtest (KFDMemoryTest.MMapLarge).

Regards,
  Felix




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux