Re: [PATCH 0/2] locking/lockdep: Track number of zapped classes & report abuse

[Waiman Long]

On 11/30/2018 09:38 AM, Waiman Long wrote:
> On 11/29/2018 05:48 PM, Peter Zijlstra wrote:
>> On Thu, Nov 29, 2018 at 05:41:35PM -0500, Waiman Long wrote:
>>> When a kernel module is repeatedly load and unload, it will eventually
>>> exhaust the lockdep entries resulting in a bug message. This is a use
>>> case that the current lockdep code cannot support.
>>>
>>> This patchset tracks the number of zapped classes and print a warning if
>>> too many lockdep entries are wasted because of too many module unloading.
>>> For example,
>>>
>>> [ 2490.651531] BUG: MAX_LOCKDEP_KEYS too low!
>>> [ 2490.669925] turning off the locking correctness validator.
>>> [ 2490.669925] Please attach the output of /proc/lock_stat to the bug report
>>> [ 2490.669926] ========================================================
>>> [ 2490.669927] WARNING: 6499 out of 8191 locks have been destroyed
>>> [ 2490.669927] through kernel module unload operations.
>>> [ 2490.669928] The corresponding lockdep entries are not reusable.
>>> [ 2490.669928] The system might have run out of lockdep entries because
>>> [ 2490.669929] of repeated kernel module load and unload operations.
>>> [ 2490.669929] Lockdep cannot support this particular use case.
>>> [ 2490.669930] --------------------------------------------------------
>> Have a look here:
>>
>>   https://lkml.kernel.org/r/20181128234325.110011-1-bvanassche@xxxxxxx
> Thanks for the pointer, I will take a look at that.
>
> Cheers,
> Longman
>
I have finished reviewing Bart's v2 patch. It enables the reuse of
lock_classes[] and list_entries[] entries. However, the stack_trace[],
lock_chains[] and chain_hlocks[] entries will still be exhausted over
time. So it doesn't completely solve the issue that I am looking at.

As a side note, an alternative way of solving the workqueue lockdep
problem may be to mark the lockdep key as special that it will hash the
actual lock address as part of the key so that each unique lock of the
same key will have its own unique lock class. That may be able to fix
the issue as well. Just a thought.

Cheers,
Longman