Re: alloc_skb called nonatomically from interrupt.. 2.1.84

Linus Torvalds (torvalds@transmeta.com)
Mon, 2 Feb 1998 10:44:30 -0800 (PST)

On Fri, 30 Jan 1998, David S. Miller wrote:
>
> Just received the above (title) upon booting 2.1.84. The reported
> address translated to inet6_rt_notify, and repeated 4 times.
>
> Linus, let's decide what we want the semantics of certain things to
> be. The new definition of in_interrupt() in linux/interrupt.h (which
> btw in an of itself is a no-no, it references elements of the
> interrupt protection mechanism which we both agreed would be
> per-architecture and therefore should not be mentioned by name in a
> generic header) counts "in interrupt" as either being within a true HW
> IRQ handler or within a BH, however now code which does:

Yes, an interrupt context is either running in a bh or in an interrupt.
Neither must ever sleep.

> net_foo()
> {
> /* We run from user context, but need to protect
> * against incoming packet handling code...
> */
> start_bh_atomic();
> ...
> /* This now doesn't work with the current code... */
> skb = alloc_skb(size, GFP_KERNEL);
> ...
> end_bh_atomic();
> }
>
> won't work anymore...

Sure, the above works fine. It's not actually running in a bottom half
handler, it's just protected against bottom half handlers.

2.1.83 may have been broken in this regard, although I doubt it. 2.1.84
certainly is not.

Note that sleeping with bh's disabled can be considered a bug in itself:
what if the wakeup mechanism requires bh's to work? The current kernel
won't complain, but you may have a dead machine on your hands.

Linus