Re: [RFC] propagate gfp_t to page table alloc functions

[Nick Piggin <npiggin@gmail.com>]

2012/4/24 Minchan Kim <minchan@kernel.org>:
> 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@kernel.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.

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>