All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: "Levin, Alexander (Sasha Levin)" <alexander.levin@verizon.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	John Hubbard <jhubbard@nvidia.com>,
	Andreas Dilger <adilger@dilger.ca>,
	Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH 1/9] mm: introduce kv[mz]alloc helpers
Date: Fri, 2 Jun 2017 09:28:56 +0200	[thread overview]
Message-ID: <20170602072855.GB29840@dhcp22.suse.cz> (raw)
In-Reply-To: <20170602071718.zk3ujm64xesoqyrr@sasha-lappy>

On Fri 02-06-17 07:17:22, Sasha Levin wrote:
> On Mon, Mar 06, 2017 at 11:30:24AM +0100, Michal Hocko wrote:
> > +void *kvmalloc_node(size_t size, gfp_t flags, int node)
> > +{
> > +	gfp_t kmalloc_flags = flags;
> > +	void *ret;
> > +
> > +	/*
> > +	 * vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables)
> > +	 * so the given set of flags has to be compatible.
> > +	 */
> > +	WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
> 
> Hm, there are quite a few locations in the kernel that do something like:
> 
> 	__vmalloc(len, GFP_NOFS, PAGE_KERNEL);
> 
> According to your patch, vmalloc can't really do GFP_NOFS, right?

Yes. It is quite likely that they will just work because the hardcoded
GFP_KERNEL inside the vmalloc path is in unlikely paths (page table
allocations for example) but yes they are broken. I didn't convert some
places which opencode the kvmalloc with GFP_NOFS because I strongly
_believe_ that the GFP_NOFS should be revisited, checked whether it is
needed, documented if so and then memalloc_nofs__{save,restore} be used
for the scope which is reclaim recursion unsafe. This would turn all
those vmalloc users to the default GFP_KERNEL and still do the right
thing.
-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: "Levin, Alexander (Sasha Levin)" <alexander.levin@verizon.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	John Hubbard <jhubbard@nvidia.com>,
	Andreas Dilger <adilger@dilger.ca>,
	Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH 1/9] mm: introduce kv[mz]alloc helpers
Date: Fri, 2 Jun 2017 09:28:56 +0200	[thread overview]
Message-ID: <20170602072855.GB29840@dhcp22.suse.cz> (raw)
In-Reply-To: <20170602071718.zk3ujm64xesoqyrr@sasha-lappy>

On Fri 02-06-17 07:17:22, Sasha Levin wrote:
> On Mon, Mar 06, 2017 at 11:30:24AM +0100, Michal Hocko wrote:
> > +void *kvmalloc_node(size_t size, gfp_t flags, int node)
> > +{
> > +	gfp_t kmalloc_flags = flags;
> > +	void *ret;
> > +
> > +	/*
> > +	 * vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables)
> > +	 * so the given set of flags has to be compatible.
> > +	 */
> > +	WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
> 
> Hm, there are quite a few locations in the kernel that do something like:
> 
> 	__vmalloc(len, GFP_NOFS, PAGE_KERNEL);
> 
> According to your patch, vmalloc can't really do GFP_NOFS, right?

Yes. It is quite likely that they will just work because the hardcoded
GFP_KERNEL inside the vmalloc path is in unlikely paths (page table
allocations for example) but yes they are broken. I didn't convert some
places which opencode the kvmalloc with GFP_NOFS because I strongly
_believe_ that the GFP_NOFS should be revisited, checked whether it is
needed, documented if so and then memalloc_nofs__{save,restore} be used
for the scope which is reclaim recursion unsafe. This would turn all
those vmalloc users to the default GFP_KERNEL and still do the right
thing.
-- 
Michal Hocko
SUSE Labs

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

  reply	other threads:[~2017-06-02  7:29 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-06 10:30 [PATCH 0/6 v5] kvmalloc Michal Hocko
2017-03-06 10:30 ` Michal Hocko
2017-03-06 10:30 ` [PATCH 1/9] mm: introduce kv[mz]alloc helpers Michal Hocko
2017-03-06 10:30   ` Michal Hocko
2017-06-02  7:17   ` Levin, Alexander (Sasha Levin)
2017-06-02  7:17     ` Levin, Alexander (Sasha Levin)
2017-06-02  7:28     ` Michal Hocko [this message]
2017-06-02  7:28       ` Michal Hocko
2017-06-02  7:40       ` Levin, Alexander (Sasha Levin)
2017-06-02  7:40         ` Levin, Alexander (Sasha Levin)
2017-06-02  7:50         ` Michal Hocko
2017-06-02  7:50           ` Michal Hocko
2017-03-06 10:30 ` [PATCH 2/9] mm: support __GFP_REPEAT in kvmalloc_node for >32kB Michal Hocko
2017-03-06 10:30   ` Michal Hocko
2017-04-07  0:45   ` Shakeel Butt
2017-04-07  0:45     ` Shakeel Butt
2017-04-07  7:40     ` Michal Hocko
2017-04-07  7:40       ` Michal Hocko
2017-03-06 10:30 ` [PATCH 3/9] rhashtable: simplify a strange allocation pattern Michal Hocko
2017-03-06 10:30   ` Michal Hocko
2017-03-06 10:30 ` [PATCH 4/9] ila: " Michal Hocko
2017-03-06 10:30   ` Michal Hocko
2017-03-06 10:33 ` [PATCH 5/9] xattr: zero out memory copied to userspace in getxattr Michal Hocko
2017-03-06 10:33   ` Michal Hocko
2017-03-06 10:33   ` [PATCH 6/9] treewide: use kv[mz]alloc* rather than opencoded variants Michal Hocko
2017-03-06 10:33     ` Michal Hocko
2017-03-06 10:33   ` [PATCH 7/9] net: use kvmalloc with __GFP_REPEAT rather than open coded variant Michal Hocko
2017-03-06 10:33     ` Michal Hocko
2017-03-30 23:21     ` Shakeel Butt
2017-03-30 23:21       ` Shakeel Butt
2017-03-31  8:46       ` Michal Hocko
2017-03-31  8:46         ` Michal Hocko
2017-03-06 10:33   ` [PATCH 8/9] md: use kvmalloc rather than opencoded variant Michal Hocko
2017-03-06 10:33     ` Michal Hocko
2017-03-06 10:33   ` [PATCH 9/9] bcache: use kvmalloc Michal Hocko
2017-03-06 10:33     ` Michal Hocko
  -- strict thread matches above, loose matches on Subject: below --
2017-01-30  9:49 [PATCH 0/6 v3] kvmalloc Michal Hocko
2017-01-30  9:49 ` [PATCH 1/9] mm: introduce kv[mz]alloc helpers Michal Hocko
2017-01-30  9:49   ` Michal Hocko

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=20170602072855.GB29840@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=adilger@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.levin@verizon.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=vbabka@suse.cz \
    /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.