[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F963B8E.9030105@kernel.org>
Date: Tue, 24 Apr 2012 14:35:10 +0900
From: Minchan Kim <minchan@...nel.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
Hugh Dickins <hughd@...gle.com>,
Johannes Weiner <hannes@...xchg.org>,
Rik van Riel <riel@...hat.com>, Mel Gorman <mgorman@...e.de>,
kosaki.motohiro@...fujitsu.com, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [RFC] propagate gfp_t to page table alloc functions
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 <minchan@...nel.org>
>
>
> 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.
>
> And, do we need to change all pud_,pgd_,pmd_,pte_alloc() for users pgtables ?
Maybe.
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists