Re: [PATCH v3 06/15] net: kunit: Suppress lock warning noise at end of dev_addr_lists tests
Jakub Kicinski <[email protected]>
| Newsgroups | gmane.linux.ports.parisc,gmane.comp.video.dri.devel,gmane.linux.kernel.cross-arch,gmane.linux.ports.arm.kernel,gmane.linux.documentation,gmane.linux.kernel,gmane.linux.ports.ppc64.devel,gmane.linux.ports.riscv,gmane.linux.ports.sh.devel,gmane.linux.network |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 3 Apr 2024 06:19:27 -0700 Guenter Roeck wrote: > dev_addr_lists_test generates lock warning noise at the end of tests > if lock debugging is enabled. There are two sets of warnings. > > WARNING: CPU: 0 PID: 689 at kernel/locking/mutex.c:923 __mutex_unlock_slowpath.constprop.0+0x13c/0x368 > DEBUG_LOCKS_WARN_ON(__owner_task(owner) != __get_current()) > > WARNING: kunit_try_catch/1336 still has locks held! > > KUnit test cleanup is not guaranteed to run in the same thread as the test > itself. For this test, this means that rtnl_lock() and rtnl_unlock() may > be called from different threads. This triggers the warnings. > Suppress the warnings because they are irrelevant for the test and just > confusing and distracting. > > The first warning can be suppressed by using START_SUPPRESSED_WARNING() > and END_SUPPRESSED_WARNING() around the call to rtnl_unlock(). To suppress > the second warning, it is necessary to set debug_locks_silent while the > rtnl lock is held. Is it okay if I move the locking into the tests, instead? It's only 4 lines more and no magic required, seems to work fine.