From: Jeff Layton <jlayton@kernel.org>
To: Alexander Duyck <alexander.duyck@gmail.com>,
Matthew Wilcox <willy@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Luis Henriques <lhenriques@suse.com>,
Christoph Hellwig <hch@lst.de>,
Carlos Maiolino <cmaiolino@redhat.com>
Subject: Re: [PATCH] mm: Make kvfree safe to call
Date: Fri, 26 Jul 2019 17:25:03 -0400 [thread overview]
Message-ID: <e4b0d323ed0bc159d863945251cf3f4c4064526c.camel@kernel.org> (raw)
In-Reply-To: <CAKgT0UcMND12oZ1869howDjcbvRj+KwabaMuRk8bmLZPWbJWcg@mail.gmail.com>
On Fri, 2019-07-26 at 14:10 -0700, Alexander Duyck wrote:
> On Fri, Jul 26, 2019 at 2:01 PM Matthew Wilcox <willy@infradead.org> wrote:
> > From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> >
> > Since vfree() can sleep, calling kvfree() from contexts where sleeping
> > is not permitted (eg holding a spinlock) is a bit of a lottery whether
> > it'll work. Introduce kvfree_safe() for situations where we know we can
> > sleep, but make kvfree() safe by default.
> >
> > Reported-by: Jeff Layton <jlayton@kernel.org>
> > Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> > Cc: Luis Henriques <lhenriques@suse.com>
> > Cc: Christoph Hellwig <hch@lst.de>
> > Cc: Carlos Maiolino <cmaiolino@redhat.com>
> > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
>
> So you say you are adding kvfree_safe() in the patch description, but
> it looks like you are introducing kvfree_fast() below. Did something
> change and the patch description wasn't updated, or is this just the
> wrong description for this patch?
>
> > ---
> > mm/util.c | 26 ++++++++++++++++++++++++--
> > 1 file changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/util.c b/mm/util.c
> > index bab284d69c8c..992f0332dced 100644
> > --- a/mm/util.c
> > +++ b/mm/util.c
> > @@ -470,6 +470,28 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)
> > }
> > EXPORT_SYMBOL(kvmalloc_node);
> >
> > +/**
> > + * kvfree_fast() - Free memory.
> > + * @addr: Pointer to allocated memory.
> > + *
> > + * kvfree_fast frees memory allocated by any of vmalloc(), kmalloc() or
> > + * kvmalloc(). It is slightly more efficient to use kfree() or vfree() if
> > + * you are certain that you know which one to use.
> > + *
> > + * Context: Either preemptible task context or not-NMI interrupt. Must not
> > + * hold a spinlock as it can sleep.
> > + */
> > +void kvfree_fast(const void *addr)
> > +{
> > + might_sleep();
> > +
might_sleep_if(!in_interrupt());
That's what vfree does anyway, so we might as well exempt the case where
you are.
> > + if (is_vmalloc_addr(addr))
> > + vfree(addr);
> > + else
> > + kfree(addr);
> > +}
> > +EXPORT_SYMBOL(kvfree_fast);
> > +
That said -- is this really useful?
The only way to know that this is safe is to know what sort of
allocation it is, and in that case you can just call kfree or vfree as
appropriate.
> > /**
> > * kvfree() - Free memory.
> > * @addr: Pointer to allocated memory.
> > @@ -478,12 +500,12 @@ EXPORT_SYMBOL(kvmalloc_node);
> > * It is slightly more efficient to use kfree() or vfree() if you are certain
> > * that you know which one to use.
> > *
> > - * Context: Either preemptible task context or not-NMI interrupt.
> > + * Context: Any context except NMI.
> > */
> > void kvfree(const void *addr)
> > {
> > if (is_vmalloc_addr(addr))
> > - vfree(addr);
> > + vfree_atomic(addr);
> > else
> > kfree(addr);
> > }
> > --
> > 2.20.1
> >
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2019-07-26 21:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-26 21:01 Matthew Wilcox
2019-07-26 21:10 ` Alexander Duyck
2019-07-26 21:25 ` Jeff Layton [this message]
2019-07-27 0:38 ` Matthew Wilcox
2019-07-27 14:54 ` Jeff Layton
2019-07-29 9:28 ` Michal Hocko
2019-07-29 13:42 ` Jason Gunthorpe
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=e4b0d323ed0bc159d863945251cf3f4c4064526c.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.duyck@gmail.com \
--cc=cmaiolino@redhat.com \
--cc=hch@lst.de \
--cc=lhenriques@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox