All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, Hugh Dickins <hughd@google.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Rik van Riel <riel@redhat.com>, Mel Gorman <mgorman@suse.de>,
	kosaki.motohiro@jp.fujitsu.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [RFC] propagate gfp_t to page table alloc functions
Date: Tue, 24 Apr 2012 14:35:10 +0900	[thread overview]
Message-ID: <4F963B8E.9030105@kernel.org> (raw)
In-Reply-To: <4F963742.2030607@jp.fujitsu.com>

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.

> 
> And, do we need to change all pud_,pgd_,pmd_,pte_alloc() for users pgtables ?


Maybe.


-- 
Kind regards,
Minchan Kim

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, Hugh Dickins <hughd@google.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Rik van Riel <riel@redhat.com>, Mel Gorman <mgorman@suse.de>,
	kosaki.motohiro@jp.fujitsu.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [RFC] propagate gfp_t to page table alloc functions
Date: Tue, 24 Apr 2012 14:35:10 +0900	[thread overview]
Message-ID: <4F963B8E.9030105@kernel.org> (raw)
In-Reply-To: <4F963742.2030607@jp.fujitsu.com>

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.

> 
> And, do we need to change all pud_,pgd_,pmd_,pte_alloc() for users pgtables ?


Maybe.


-- 
Kind regards,
Minchan Kim

  reply	other threads:[~2012-04-24  5:34 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-23  8:55 [RFC] propagate gfp_t to page table alloc functions Minchan Kim
2012-04-23  8:55 ` Minchan Kim
2012-04-24  5:16 ` KAMEZAWA Hiroyuki
2012-04-24  5:16   ` KAMEZAWA Hiroyuki
2012-04-24  5:35   ` Minchan Kim [this message]
2012-04-24  5:35     ` Minchan Kim
2012-04-24  6:13     ` Nick Piggin
2012-04-24  6:13       ` Nick Piggin
2012-04-24  7:19       ` Minchan Kim
2012-04-24  7:19         ` Minchan Kim
2012-04-24  7:48         ` Nick Piggin
2012-04-24  7:48           ` Nick Piggin
2012-04-24  8:01           ` Minchan Kim
2012-04-24  8:01             ` Minchan Kim
2012-04-24  8:05             ` Nick Piggin
2012-04-24  8:05               ` Nick Piggin
2012-04-24 21:30           ` Andrew Morton
2012-04-24 21:30             ` Andrew Morton
2012-04-24 23:49             ` KAMEZAWA Hiroyuki
2012-04-24 23:49               ` KAMEZAWA Hiroyuki
2012-04-24 23:55               ` KOSAKI Motohiro
2012-04-24 23:55                 ` KOSAKI Motohiro
2012-04-25  0:05                 ` KAMEZAWA Hiroyuki
2012-04-25  0:05                   ` KAMEZAWA Hiroyuki
2012-04-25  0:25                   ` Andrew Morton
2012-04-25  0:25                     ` Andrew Morton
2012-04-26  0:05                     ` KAMEZAWA Hiroyuki
2012-04-26  0:05                       ` KAMEZAWA Hiroyuki
2012-04-26  0:20                       ` David Rientjes
2012-04-26  0:20                         ` David Rientjes
2012-04-27  2:24                         ` Minchan Kim
2012-04-27  2:24                           ` Minchan Kim
2012-04-27  3:08                           ` Andrew Morton
2012-04-27  3:08                             ` Andrew Morton
2012-04-27 10:43                           ` David Rientjes
2012-04-27 10:43                             ` David Rientjes
2012-04-30  1:25                             ` Minchan Kim
2012-04-30  1:25                               ` Minchan Kim
2012-05-01  7:20             ` Nick Piggin
2012-05-01  7:20               ` Nick Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F963B8E.9030105@kernel.org \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=riel@redhat.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.