[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bmcqp717.fsf@notabene.neil.brown.name>
Date: Tue, 05 Jun 2018 07:37:40 +1000
From: NeilBrown <neilb@...e.com>
To: Simon Horman <simon.horman@...ronome.com>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Thomas Graf <tgraf@...g.ch>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH 15a/18] rhashtables: add lockdep tracking to bucket bit-spin-locks.
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 <neilb@...e.com>
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
Powered by blists - more mailing lists