On Wed, Feb 06, 2019 at 10:07:21AM +0100, Johannes Berg wrote: > From: Johannes Berg <[email protected]> > > When an rhashtable walk is done from softirq context, we rightfully > get a lockdep complaint saying that we could get a softirq in the > middle of a rehash, and thus deadlock on &ht->lock. This happened > e.g. in mac80211 as it does a walk in softirq context. > > Fix this by using spin_lock_bh() wherever we use the &ht->lock. > > Initially, I thought it would be sufficient to do this only in the > rehash (rhashtable_rehash_table), but I changed my mind: > * the caller doesn't really need to disable softirqs across all > of the rhashtable_walk_* functions, only those parts that they > actually do within the lock need it > * maybe more importantly, it would still lead to massive lockdep > complaints - false positives, but hard to fix - because lockdep > wouldn't know about different ht->lock instances, and thus one > user of the code doing a walk w/o any locking (when it only ever > uses process context this is fine) vs. another user like in wifi > where we noticed this problem would still cause it to complain. > > Cc: [email protected] > Reported-by: Jouni Malinen <[email protected]> > Signed-off-by: Johannes Berg <[email protected]>
This interface wasn't designed for use in softirq contexts. Could you please show me who is doing this so I can review that to see whether it's a legitimate use of this API? Thanks, -- Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
