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 /* -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
