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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 22 May 2006 13:18:18 +0200, Andi Kleen <[email protected]> said:

   > Nick Piggin <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux