From: Johannes Berg <johannes.berg@xxxxxxxxx> When an rhashtabl walk is done from irq/bh context, we rightfully get a lockdep complaint saying that we could get a (soft-)IRQ in the middle of a rehash. This happened e.g. in mac80211 as it does a walk in soft-irq context. Fix this by using irq-safe locking here. We don't need _irqsave() as we know this will be called only in process context from the workqueue. We could get away with _bh() but that seems a bit less generic, though I'm not sure anyone would want to do a walk from a real IRQ handler. Reported-by: Jouni Malinen <j@xxxxx> Signed-off-by: Johannes Berg <johannes.berg@xxxxxxxxx> --- lib/rhashtable.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/rhashtable.c b/lib/rhashtable.c index 852ffa5160f1..ad3c1da15475 100644 --- a/lib/rhashtable.c +++ b/lib/rhashtable.c @@ -327,10 +327,10 @@ static int rhashtable_rehash_table(struct rhashtable *ht) /* Publish the new table pointer. */ rcu_assign_pointer(ht->tbl, new_tbl); - spin_lock(&ht->lock); + spin_lock_irq(&ht->lock); list_for_each_entry(walker, &old_tbl->walkers, list) walker->tbl = NULL; - spin_unlock(&ht->lock); + spin_unlock_irq(&ht->lock); /* Wait for readers. All new readers will see the new * table, and thus no references to the old table will -- 2.17.2
