This warning has started to trigger with mac80211 because it can, under
some circumstances, use spin_lock_bh() protected sections within
irq-disabled sections. Is that a bug?
Interestingly, the warning was never noticed until somebody ran the code
on UP/NO-PREEMPT because local_bh_enable_ip() does not contain such a
warning. Also, because softirq disabling is refcounted (via the preempt
counter), it ought to be safe to nest it and even use within
irqs-disabled sections, as far as I can tell.
Also, if you're going to treat IRQs being enabled as a bug, there's no
point in disabling them right afterwards, is there?
If you're going to reject this patch, I'll post one that adds the
warning to local_bh_enable_ip() to allow detecting this for everybody
and not just those poor people running UP/NO-PREEMPT :)
(and why doesn't local_bh_enable just call local_bh_enable_ip anyway? or
both "call" a common static inline?)
---
kernel/softirq.c | 3 ---
1 file changed, 3 deletions(-)
--- everything.orig/kernel/softirq.c 2008-06-17 23:48:25.000000000 +0200
+++ everything/kernel/softirq.c 2008-06-17 23:48:56.000000000 +0200
@@ -137,10 +137,7 @@ void local_bh_enable(void)
unsigned long flags;
WARN_ON_ONCE(in_irq());
-#endif
- WARN_ON_ONCE(irqs_disabled());
-#ifdef CONFIG_TRACE_IRQFLAGS
local_irq_save(flags);
#endif
/*
--
