linux-kernel - Re: lock warnings in dev_addr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 29 Feb 2024 01:13:56 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: David Gow <davidgow@...gle.com>
Cc: Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 Brendan Higgins <brendanhiggins@...gle.com>,
 linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com
Subject: Re: lock warnings in dev_addr_lists test

On 2/29/24 00:10, David Gow wrote:
> On Thu, 29 Feb 2024 at 03:45, Guenter Roeck <linux@...ck-us.net> wrote:
>>
>> Hi,
>>
>> when running the dev_addr_lists unit test with lock debugging enabled,
>> I always get the following lockdep warning.
>>
>> [    7.031327] ====================================
>> [    7.031393] WARNING: kunit_try_catch/1886 still has locks held!
>> [    7.031478] 6.8.0-rc6-00053-g0fec7343edb5-dirty #1 Tainted: G        W        N
>> [    7.031728] ------------------------------------
>> [    7.031816] 1 lock held by kunit_try_catch/1886:
>> [    7.031896]  #0: ffffffff8ed35008 (rtnl_mutex){+.+.}-{3:3}, at: dev_addr_test_init+0x6a/0x100
>>
>> Instrumentation shows that dev_addr_test_exit() is called, but only
>> after the warning fires.
>>
>> Is this a problem with kunit tests or a problem with this specific test ?
> 
> A bit of both, I think. KUnit test cleanup is not guaranteed to run in
> the same thread as the test, so that definitely is triggering lockdep
> warnings.
> 
> On the other hand, we really should make this particular case work in
> KUnit. Ideally test cleanup will happen on the test thread first, and
> only fall back to another test if the test thread otherwise aborted.
> 
> So, this is probably something we won't be able to fix if the test
> fails, but it definitely shouldn't be happening here where it passes.
> I'll look into fixing that.
> 

Here is a different warning, from the same test:

[   10.622270] =====================================
[   10.622346] WARNING: bad unlock balance detected!
[   10.622481] 6.8.0-rc6 #1 Tainted: G                 N
[   10.622624] -------------------------------------
[   10.622698] kunit_try_catch/1354 is trying to release lock (rtnl_mutex) at:
[   10.623123] [<ffffd7c5cbdb75cc>] __rtnl_unlock+0x3c/0x84
[   10.623538] but there are no more locks to release!

That seems to be kind of the opposite problem. I noticed this only
once in my tests, so it is much rarer than the other warning.

Guenter