All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
	lhenriques@suse.com, cmaiolino@redhat.com,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH] mm: check for sleepable context in kvfree
Date: Tue, 23 Jul 2019 11:29:44 -0700	[thread overview]
Message-ID: <20190723182944.GO363@bombadil.infradead.org> (raw)
In-Reply-To: <d7cd46333eb1a29fb7e0e078dc4fef7646fe2a8c.camel@kernel.org>

On Tue, Jul 23, 2019 at 02:19:03PM -0400, Jeff Layton wrote:
> On Tue, 2019-07-23 at 11:11 -0700, Matthew Wilcox wrote:
> > On Tue, Jul 23, 2019 at 02:05:11PM -0400, Jeff Layton wrote:
> > > On Tue, 2019-07-23 at 10:55 -0700, Matthew Wilcox wrote:
> > > > I think it's a bit of a landmine, to be honest.  How about we have kvfree()
> > > > call vfree_atomic() instead?
> > > 
> > > Not a bad idea, though it means more overhead for the vfree case.
> > > 
> > > Since we're spitballing here...could we have kvfree figure out whether
> > > it's running in a context where it would need to queue it instead and
> > > only do it in that case?
> > > 
> > > We currently have to figure that out for the might_sleep_if anyway. We
> > > could just have it DTRT instead of printk'ing and dumping the stack in
> > > that case.
> > 
> > I don't think we have a generic way to determine if we're currently
> > holding a spinlock.  ie this can fail:
> > 
> > spin_lock(&my_lock);
> > kvfree(p);
> > spin_unlock(&my_lock);
> > 
> > If we're preemptible, we can check the preempt count, but !CONFIG_PREEMPT
> > doesn't record the number of spinlocks currently taken.
> 
> Ahh right...that makes sense.
> 
> Al also suggested on IRC that we could add a kvfree_atomic if that were
> useful. That might be good for new callers, but we'd probably need a
> patch like this one to suss out which of the existing kvfree callers
> would need to switch to using it.
> 
> I think you're quite right that this is a landmine. That said, this
> seems like something we ought to try to clean up.

I'd rather add a kvfree_fast().  So something like this:

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();
+
+	if (is_vmalloc_addr(addr))
+		vfree(addr);
+	else
+		kfree(addr);
+}
+EXPORT_SYMBOL(kvfree_fast);
+
 /**
  * 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);
 }


      reply	other threads:[~2019-07-23 18:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-23 13:12 [PATCH] mm: check for sleepable context in kvfree Jeff Layton
2019-07-23 17:52 ` Jeff Layton
2019-07-23 17:55   ` Matthew Wilcox
2019-07-23 18:05     ` Jeff Layton
2019-07-23 18:11       ` Matthew Wilcox
2019-07-23 18:19         ` Jeff Layton
2019-07-23 18:29           ` Matthew Wilcox [this message]

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=20190723182944.GO363@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=cmaiolino@redhat.com \
    --cc=hch@lst.de \
    --cc=jlayton@kernel.org \
    --cc=lhenriques@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.