Re: __vmalloc with GFP_ATOMIC causes 'sleeping from invalid context'
From: Giridhar Pemmasani
Date: Mon May 22 2006 - 11:12:30 EST
On 22 May 2006 13:18:18 +0200, Andi Kleen <ak@xxxxxxx> said:
> Nick Piggin <nickpiggin@xxxxxxxxxxxx> writes:
>> Giridhar Pemmasani wrote: > If __vmalloc is called in atomic
>> context with GFP_ATOMIC flags, > __get_vm_area_node is called,
>> which calls kmalloc_node with GFP_KERNEL > flags. This causes
>> 'sleeping function called from invalid context at >
>> mm/slab.c:2729' with 2.6.16-rc4 kernel. A simple solution is to
>> I can't see what would cause this in either 2.6.16-rc4 or
>> 2.6.17-rc4. What is the line?
>> > proper flags in __get_vm_area_node, depending on the context:
>> I don't think that always works, you might pass in GFP_ATOMIC due
>> to having hold of a spinlock, for example.
>> Also, vmlist_lock isn't interrupt safe, so it still kind of goes
>> against the spirit of GFP_ATOMIC (which is to allow allocation
>> from interrupt context).
> That's not the only problem. Allocating page table entries or
> flushing TLBs from an atomic context is just not supported by the
> low level architecture code.
I looked through __vmalloc implementation and the call tree. Nowhere
do I see a problem with calling __vmalloc in atomic context (with
GFP_ATOMIC flags, of course). Except for a few architectures (arm,
m68k, sparc and xtensa), flusch_cache_all is a nop. I didn't look into
all architectures, but at least for m68k, flush_cache_all seems to
safe in atomic context. Please correct me if I am wrong.
To reiterate, __get_vm_area_node allocates space for 'struct
vm_struct' with GFP_KERNEL irrespective of how its caller was called -
if __vmalloc was called with GFP_ATOMIC, the node for that allocation
should be allocated with the same flags. So the patch I suggested
simply passes the flags from __vmalloc down to __get_vm_area_node.
If indeed it is not safe to call __vmalloc in atomic context (even
with GFP_ATOMIC flags), perhaps we can add BUG_ON(in_atomic()) to
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/