On Mon, Jun 04 2018, Simon Horman wrote: > On Mon, Jun 04, 2018 at 12:52:54PM +1000, NeilBrown wrote: >> >> Native bit_spin_locks are not tracked by lockdep. >> >> The bit_spin_locks used for rhashtable buckets are local >> to the rhashtable implementation, so there is little opportunity >> for the sort of misuse that lockdep might detect. >> However locks are held while a hash function or compare >> function is called, and if one of these took a lock, >> a misbehaviour is possible. >> >> As it is quite easy to add lockdep support this unlikely >> possibility see to be enough justification. > > nit: s/see/seems/ > Thanks :-) I've made that change for when I formally submit. Thanks, NeilBrown >> >> So create a lockdep class for bucket bit_spin_lock as attach >> through a lockdep_map in each bucket_table. >> >> With the 'nested' annotation in rhashtable_rehash_one(), lockdep >> correctly reports a possible problem as this lock it taken >> while another bucket lock (in another table) is held. This >> confirms that the added support works. >> With the correct nested annotation in place, lockdep reports >> no problems. >> >> Signed-off-by: NeilBrown