All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>,
	David Miller <davem@davemloft.net>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [RFC][PATCH] making vfree() safe from interrupt contexts
Date: Sun, 3 Mar 2013 19:32:23 +0000	[thread overview]
Message-ID: <20130303193223.GN4503@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20130303184736.GM4503@ZenIV.linux.org.uk>

On Sun, Mar 03, 2013 at 06:47:36PM +0000, Al Viro wrote:
> 	To bring back the thing discussed back in, IIRC, December: we have
> a bunch of places where inability to do vfree() from interrupt contexts
> (the most common case is doing that from RCU callback) leads to very
> ugly open-coded schemes that delay it one way or another.  We can let vfree()
> itself do that instead.  AFAICS, it works; the diff below covers several
> obvious cases found just by grep.  I'm fairly sure that there's more code
> that could benefit from that...
> 
> 	I'm not sure which tree should it go through, though.  Suggestions?
> The reason I'm interested in this sucker is the mess in fs/file.c (fdtable
> freeing), but the main change here is in mm/vmalloc.c...
> 
> 	Note that the patch obviously ought to be split - mm/vmalloc.c
> part, allowing vfree() in interrupt contexts (current mainline has
> BUG_ON() triggered in that case) and a chunk for each ad-hoc vfree()
> deferral scheme killed.
> 
> 	Comments?

BTW, looking a bit more shows another place that might benefit from that -
kernel/events/ring_buffer.c:rb_free_work() is called via schedule_work()
and I don't see anything in it besides vfree() that would demand that
kind of treatment.

  reply	other threads:[~2013-03-03 19:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-03 18:47 [RFC][PATCH] making vfree() safe from interrupt contexts Al Viro
2013-03-03 19:32 ` Al Viro [this message]
2013-03-03 22:34 ` Linus Torvalds
2013-03-03 22:51   ` Al Viro
2013-03-03 23:01     ` Linus Torvalds

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=20130303193223.GN4503@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=torvalds@linux-foundation.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.