From: Michal Hocko <mhocko@kernel.org>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrew Morton <akpm@linux-foundation.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Vlastimil Babka <vbabka@suse.cz>,
Andreas Dilger <adilger@dilger.ca>,
John Hubbard <jhubbard@nvidia.com>,
David Miller <davem@davemloft.net>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
netdev@vger.kernel.org
Subject: Re: [PATCH] vmalloc: respect the GFP_NOIO and GFP_NOFS flags
Date: Mon, 3 Jul 2017 08:31:18 +0200 [thread overview]
Message-ID: <20170703062905.GB3217@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.LRH.2.02.1706302033230.13879@file01.intranet.prod.int.rdu2.redhat.com>
On Fri 30-06-17 20:36:12, Mikulas Patocka wrote:
>
>
> On Fri, 30 Jun 2017, Michal Hocko wrote:
>
> > On Fri 30-06-17 14:11:57, Mikulas Patocka wrote:
> > >
> > >
> > > On Fri, 30 Jun 2017, Michal Hocko wrote:
> > >
> > > > On Thu 29-06-17 22:25:09, Mikulas Patocka wrote:
> > > > > The __vmalloc function has a parameter gfp_mask with the allocation flags,
> > > > > however it doesn't fully respect the GFP_NOIO and GFP_NOFS flags. The
> > > > > pages are allocated with the specified gfp flags, but the pagetables are
> > > > > always allocated with GFP_KERNEL. This allocation can cause unexpected
> > > > > recursion into the filesystem or I/O subsystem.
> > > > >
> > > > > It is not practical to extend page table allocation routines with gfp
> > > > > flags because it would require modification of architecture-specific code
> > > > > in all architecturs. However, the process can temporarily request that all
> > > > > allocations are done with GFP_NOFS or GFP_NOIO with with the functions
> > > > > memalloc_nofs_save and memalloc_noio_save.
> > > > >
> > > > > This patch makes the vmalloc code use memalloc_nofs_save or
> > > > > memalloc_noio_save if the supplied gfp flags do not contain __GFP_FS or
> > > > > __GFP_IO. It fixes some possible deadlocks in drivers/mtd/ubi/io.c,
> > > > > fs/gfs2/, fs/btrfs/free-space-tree.c, fs/ubifs/,
> > > > > fs/nfs/blocklayout/extent_tree.c where __vmalloc is used with the GFP_NOFS
> > > > > flag.
> > > >
> > > > I strongly believe this is a step in the _wrong_ direction. Why? Because
> > >
> > > What do you think __vmalloc with GFP_NOIO should do? Print a warning?
> > > Silently ignore the GFP_NOIO flag?
> >
> > I think noio users are not that much different from nofs users. Simply
> > use the scope API at the place where the scope starts and document why
> > it is needed. vmalloc calls do not have to be any special then and they
> > do not even have to think about proper gfp flags and they can use
> > whatever is the default.
> > --
> > Michal Hocko
> > SUSE Labs
>
> But you didn't answer the question - what should __vmalloc with GFP_NOIO
> (or GFP_NOFS) do? Silently drop the flag? Print a warning? Or respect the
> flag?
We can add a warning (or move it from kvmalloc) and hope that the
respective maintainers will fix those places properly. The reason I
didn't add the warning to vmalloc and kept it in kvmalloc was to catch
only new users rather than suddenly splat on existing ones. Note that
there are users with panic_on_warn enabled.
Considering how many NOFS users we have in tree I would rather work with
maintainers to fix them.
> Currently, it silently drops the GFP_NOIO or GFP_NOFS flag, but some
> programmers don't know it and use these flags. You can't blame those
> programmers for not knowing it.
At least __vmalloc_node is documented to not support all gfp flags.
--
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>
next prev parent reply other threads:[~2017-07-03 6:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-30 2:25 Mikulas Patocka
2017-06-30 6:20 ` John Hubbard
2017-06-30 8:12 ` Michal Hocko
2017-06-30 18:11 ` Mikulas Patocka
2017-06-30 20:41 ` Michal Hocko
2017-07-01 0:36 ` Mikulas Patocka
2017-07-03 6:31 ` Michal Hocko [this message]
2017-07-03 22:57 ` Mikulas Patocka
2017-07-04 8:10 ` Michal Hocko
2017-07-01 3:25 ` Andreas Dilger
2017-07-01 4:49 ` Mikulas Patocka
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=20170703062905.GB3217@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=adilger@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpatocka@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox