Re: __vmalloc with GFP_ATOMIC causes 'sleeping from invalid context'

[Giridhar Pemmasani <giri@lmc.cs.sunysb.edu>]

On 22 May 2006 13:18:18 +0200, Andi Kleen <ak@suse.de> said:

   > Nick Piggin <nickpiggin@yahoo.com.au> 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
  >> use
  >> 
  >> 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
__vmalloc?

Thanks,
Giri
-
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/