Real-Time Preemption and GFP_ATOMIC

[Kevin Hilman <kevin@hilman.org>]

While testing an older driver on an -RT kernel (currently using
-V0.7.37-03), I noticed something strange.

The driver was triggering a "sleeping function called from invalid
context" BUG().  It was coming from a case where the driver was doing
a __get_free_page(GFP_ATOMIC) while interrupts were disabled (example
trace below).  I know this is probably real bug and it shouldn't be
allocating memory with interrupts disabled, but shouldn't this be
possible?  Isn't the role of GFP_ATOMIC to say that "this caller
cannot sleep". 

To produce the following trace, I wrote a simple moudle which just has
this as its init_module routine:

        local_irq_disable();
        p = __get_free_page(GFP_ATOMIC);
        local_irq_enable();
 
And here's the trace:

BUG: sleeping function called from invalid context insmod(2126) at kernel/rt.c:1448
in_atomic():0 [00000000], irqs_disabled():1
 [<c0102fa3>] dump_stack+0x23/0x30 (20)
 [<c01133c5>] __might_sleep+0xe5/0x100 (36)
 [<c012fbb8>] __spin_lock+0x38/0x60 (24)
 [<c012fc8d>] _spin_lock_irqsave+0x1d/0x30 (16)
 [<c0140e5c>] buffered_rmqueue+0x1c/0x190 (40)
 [<c01413ce>] __alloc_pages+0x34e/0x390 (76)
 [<c0141437>] __get_free_pages+0x27/0x50 (12)
 [<c883205a>] kmod_init+0x5a/0x74 [kmod] (24)
 [<c0138232>] sys_init_module+0x232/0x260 (28)
 [<c010299c>] syscall_call+0x7/0xb (-8124)
---------------------------
| preempt count: 00000001 ]
| 1-level deep critical section nesting:
----------------------------------------
.. [<c0133e3d>] .... print_traces+0x1d/0x60
.....[<c0102fa3>] ..   ( <= dump_stack+0x23/0x30)