[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190205143706.28371-1-johannes@sipsolutions.net>
Date: Tue, 5 Feb 2019 15:37:06 +0100
From: Johannes Berg <johannes@...solutions.net>
To: linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Cc: Jouni Malinen <j@...fi>, Thomas Graf <tgraf@...g.ch>,
Herbert Xu <herbert@...dor.apana.org.au>,
Johannes Berg <johannes.berg@...el.com>
Subject: [PATCH] rhashtable: use irq-safe spinlock in rhashtable_rehash_table()
From: Johannes Berg <johannes.berg@...el.com>
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@...fi>
Signed-off-by: Johannes Berg <johannes.berg@...el.com>
---
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
Powered by blists - more mailing lists