Already fixed on upstream.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/locking?h=v4.18-rc4&id=03eeafdd9ab06a770d42c2b264d50dff7e2f4eee
________________________________
From: Pan, Xinhui
Sent: Friday, July 13, 2018 6:17:06 PM
To: Kuehling, Felix; Michel Dänzer
Cc: amd-gfx@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@daenzer.net>; Pan, Xinhui <Xinhui.Pan@amd.com>
Cc: amd-gfx@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