Re: [PATCH 25/27] locking/lockdep: Add support for dynamic keys

[Bart Van Assche]

On Thu, 2018-11-29 at 13:04 +-0100, Peter Zijlstra wrote:
+AD4 On Wed, Nov 28, 2018 at 03:43:23PM -0800, Bart Van Assche wrote:
+AD4 +AD4 A shortcoming of the current lockdep implementation is that it requires
+AD4 +AD4 lock keys to be allocated statically. That forces certain lock objects
+AD4 +AD4 to share lock keys. Since lock dependency analysis groups lock objects
+AD4 +AD4 per key sharing lock keys can cause false positive lockdep reports.
+AD4 +AD4 Make it possible to avoid such false positive reports by allowing lock
+AD4 +AD4 keys to be allocated dynamically. Require that dynamically allocated
+AD4 +AD4 lock keys are registered before use by calling lockdep+AF8-register+AF8-key().
+AD4 +AD4 Complain about attempts to register the same lock key pointer twice
+AD4 +AD4 without calling lockdep+AF8-unregister+AF8-key() between successive
+AD4 +AD4 registration calls.
+AD4 +AD4  struct lock+AF8-class+AF8-key +AHs
+AD4 +AD4 +-	struct hlist+AF8-node		hash+AF8-entry+ADs
+AD4 +AD4  	struct lockdep+AF8-subclass+AF8-key	subkeys+AFs-MAX+AF8-LOCKDEP+AF8-SUBCLASSES+AF0AOw
+AD4 +AD4  +AH0AOw
+AD4 
+AD4 That hash+AF8-entry is purely for that double-register warning, right? I
+AD4 wonder if we can do that differently+ADs by always doing
+AD4 register+AF8-lock+AF8-class(), and checking that state.

Hi Peter,

The hash+AF8-entry serves two purposes. One purpose is to verify whether the
lockdep+AF8-register+AF8-key() and  lockdep+AF8-unregister+AF8-key() functions are used
correctly. A second purpose is to avoid that lockdep+AF8-init+AF8-map() complains
when encountering a dynamically allocated key. I'm not sure how always
doing register+AF8-lock+AF8-class() would help?

Thanks,

Bart.