From: Andrew Morton <akpm@linux-foundation.org>
Date: Fri, 30 Jan 2009 21:49:33 -0800

quoted text
> Hang on.  You said
> 
>   That's typically for softirq vs non softirq, which is important for
>   the network stack.
> 
> that's what in_softirq() does.
> 
> Now, if networking is indeed using in_atomic() to detect
> are-we-inside-a-spinlock then networking is buggy.
> 
> If networking is _not_ doing that then we can safely switch it to
> in_sortirq() or in_interrupt().  And this would reenable the bug
> detection which networking's use of in_atomic() accidentally
> suppressed.

I think this is a reasonable conclusion, looking at the
gfp_any() users.

Feel free to change it to use in_softirq() and see what
explodes in -mm.  Report to me your findings :-)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html