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

[Pan, Xinhui]

I think this is a kernel bug. See patch
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/locking?h=v4.18-rc4&id=03eeafdd9ab06a770d42c2b264d50dff7e2f4eee


-----Original Message-----
From: Pan, Xinhui 
Sent: 2018年7月13日 18:17
To: Kuehling, Felix <Felix.Kuehling at amd.com>; Michel Dänzer <michel at daenzer.net>
Cc: amd-gfx at lists.freedesktop.org
Subject: RE: DEBUG_LOCKS_WARN_ON(sem->owner != ((struct task_struct *)(1UL << 0)))

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