Messages in this thread | | | Subject | Real-Time Preemption and GFP_ATOMIC | From | Kevin Hilman <> | Date | 02 Feb 2005 10:48:54 -0800 |
| |
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)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |