Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750921AbWEVPND (ORCPT ); Mon, 22 May 2006 11:13:03 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750925AbWEVPNC (ORCPT ); Mon, 22 May 2006 11:13:02 -0400 Received: from lmcgw.cs.sunysb.edu ([130.245.128.4]:46817 "EHLO smtp.lmc.cs.sunysb.edu") by vger.kernel.org with ESMTP id S1750921AbWEVPNA (ORCPT ); Mon, 22 May 2006 11:13:00 -0400 Date: Mon, 22 May 2006 11:12:58 -0400 From: Giridhar Pemmasani To: Andi Kleen Cc: Nick Piggin , linux-kernel@vger.kernel.org Subject: Re: __vmalloc with GFP_ATOMIC causes 'sleeping from invalid context' In-Reply-To: References: <20060522013648.6FCEAEE9EE@wolfe.lmc.cs.sunysb.edu> <447119B3.7000506@yahoo.com.au> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 MULE XEmacs/21.4 (patch 19) (Constant Variable) (i386-debian-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20060522151258.F1259EE9EE@wolfe.lmc.cs.sunysb.edu> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2239 Lines: 51 On 22 May 2006 13:18:18 +0200, Andi Kleen said: > Nick Piggin 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/