From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Horman Subject: Re: [PATCH 15a/18] rhashtables: add lockdep tracking to bucket bit-spin-locks. Date: Mon, 4 Jun 2018 20:16:10 +0200 Message-ID: <20180604181609.sssd4ao6wfwj3il6@netronome.com> References: <152782754287.30340.4395718227884933670.stgit@noble> <152782824984.30340.1634082820568216846.stgit@noble> <20180602050322.liesw324q5kawcue@gondor.apana.org.au> <9bea77df-e7db-677a-31b2-710dc6d956ee@gmail.com> <871sdnqty4.fsf@notabene.neil.brown.name> <87po17p8jd.fsf@notabene.neil.brown.name> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Eric Dumazet , Herbert Xu , Thomas Graf , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "David S. Miller" To: NeilBrown Return-path: Content-Disposition: inline In-Reply-To: <87po17p8jd.fsf@notabene.neil.brown.name> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org 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/ > > 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