From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx142.postini.com [74.125.245.142]) by kanga.kvack.org (Postfix) with SMTP id 205446B0044 for ; Tue, 24 Apr 2012 02:13:06 -0400 (EDT) Received: by obbeh20 with SMTP id eh20so658429obb.14 for ; Mon, 23 Apr 2012 23:13:05 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4F963B8E.9030105@kernel.org> References: <1335171318-4838-1-git-send-email-minchan@kernel.org> <4F963742.2030607@jp.fujitsu.com> <4F963B8E.9030105@kernel.org> Date: Tue, 24 Apr 2012 16:13:05 +1000 Message-ID: Subject: Re: [RFC] propagate gfp_t to page table alloc functions From: Nick Piggin Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: KAMEZAWA Hiroyuki , Andrew Morton , Ingo Molnar , x86@kernel.org, Hugh Dickins , Johannes Weiner , Rik van Riel , Mel Gorman , kosaki.motohiro@jp.fujitsu.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org 2012/4/24 Minchan Kim : > On 04/24/2012 02:16 PM, KAMEZAWA Hiroyuki wrote: > >> (2012/04/23 17:55), Minchan Kim wrote: >> >>> As I test some code, I found a problem about deadlock by lockdep. >>> The reason I saw the message is __vmalloc calls map_vm_area which calls >>> pud/pmd_alloc without gfp_t. so although we call __vmalloc with >>> GFP_ATOMIC or GFP_NOIO, it ends up allocating pages with GFP_KERNEL. >>> The should be a BUG. This patch fixes it by passing gfp_to to low page >>> table allocate functions. >>> >>> Signed-off-by: Minchan Kim >> >> >> Hmm ? vmalloc should support GFP_ATOMIC ? > > > I'm not sure but alloc_large_system_hash already has used. > And it's not specific on GFP_ATOMIC. > We have to care of GFP_NOFS and GFP_NOIO to prevent deadlock on reclaim > context. > There are some places to use GFP_NOFS and we don't emit any warning > message in case of that. What's the lockdep warning? vmalloc was never supposed to use gfp flags for allocation "context" restriction. I.e., it was always supposed to have blocking, fs, and io capable allocation context. The flags were supposed to be a memory type modifier. These different classes of flags is a bit of a problem and source of confusion we have. We should be doing more checks for them, of course. I suspect you need to fix the caller? Thanks, Nick -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org