* [PATCH] rhashtable: use irq-safe spinlock in rhashtable_rehash_table()
@ 2019-02-05 14:37 Johannes Berg
2019-02-06 8:15 ` Johannes Berg
0 siblings, 1 reply; 3+ messages in thread
From: Johannes Berg @ 2019-02-05 14:37 UTC (permalink / raw)
To: linux-wireless, netdev
Cc: Jouni Malinen, Thomas Graf, Herbert Xu, Johannes Berg
From: Johannes Berg <johannes.berg@intel.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@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.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
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] rhashtable: use irq-safe spinlock in rhashtable_rehash_table()
2019-02-05 14:37 [PATCH] rhashtable: use irq-safe spinlock in rhashtable_rehash_table() Johannes Berg
@ 2019-02-06 8:15 ` Johannes Berg
2019-02-06 17:40 ` David Miller
0 siblings, 1 reply; 3+ messages in thread
From: Johannes Berg @ 2019-02-06 8:15 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: Jouni Malinen, Thomas Graf, Herbert Xu
On Tue, 2019-02-05 at 15:37 +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.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.
Please drop this, it doesn't make sense.
I'll resend with all the spinlock usage changed to either _bh or
_irqsave(), since it makes no sense to enforce any kind of outside
BH/irq disabling for purposes of the inner lock.
johannes
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] rhashtable: use irq-safe spinlock in rhashtable_rehash_table()
2019-02-06 8:15 ` Johannes Berg
@ 2019-02-06 17:40 ` David Miller
0 siblings, 0 replies; 3+ messages in thread
From: David Miller @ 2019-02-06 17:40 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev, j, tgraf, herbert
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 06 Feb 2019 09:15:15 +0100
> On Tue, 2019-02-05 at 15:37 +0100, Johannes Berg wrote:
>> From: Johannes Berg <johannes.berg@intel.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.
>
> Please drop this, it doesn't make sense.
>
> I'll resend with all the spinlock usage changed to either _bh or
> _irqsave(), since it makes no sense to enforce any kind of outside
> BH/irq disabling for purposes of the inner lock.
Ok.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-02-06 17:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-05 14:37 [PATCH] rhashtable: use irq-safe spinlock in rhashtable_rehash_table() Johannes Berg
2019-02-06 8:15 ` Johannes Berg
2019-02-06 17:40 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).