On Wed, 2013-05-08 at 16:47 +0800, wyang1 wrote: > On 05/08/2013 04:37 PM, Johannes Berg wrote: > > On Wed, 2013-05-08 at 10:36 +0200, Johannes Berg wrote: > >> On Wed, 2013-05-08 at 16:31 +0800, Wei.Yang@xxxxxxxxxxxxx wrote: > >>> From: Wei Yang <Wei.Yang@xxxxxxxxxxxxx> > >>> > >>> In case of RT kernel, the return value of softirq_count() always > >>> equal to 0, we need to use in_serving_softirq to decide whether > >>> the current context is in softirq context. > >>> - WARN_ON_ONCE(softirq_count() == 0); > >>> + WARN_ON_ONCE(!in_serving_softirq()); > >> As I understand the code, I don't believe this change to be correct. The > >> function can happily run with softirqs disabled (e.g. > >> local_bh_disable()), for example by being called via ieee80211_rx_ni(). > >> As I understand in_serving_softirq(), it checks that it's actually > >> inside handling a softirq, no? > > Arguably, it should be > > WARN_ON_ONCE(!in_softirq()); > > > > but that's equivalent: > > Yeah, but the softirq is threaded in rt kernel, the softirq_count always > return 0. The warning should always happen with rt kernel. So maybe then the RT kernel defines in_softirq() appropriately and you should submit a patch to change to using that? I find it hard to believe that the RT kernel breaks _all_ the softirq APIs, but hey, I know nothing about RT :-) johannes -- 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
