All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Rik van Riel <riel@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Takashi Iwai <tiwai@suse.de>
Subject: Re: [RFC] revoke(2) and generic handling of things like remove_proc_entry()
Date: Fri, 12 Apr 2013 00:29:13 +0100	[thread overview]
Message-ID: <20130411232913.GC4068@ZenIV.linux.org.uk> (raw)
In-Reply-To: <877gk8vlnp.fsf@xmission.com>

On Thu, Apr 11, 2013 at 01:48:26PM -0700, Eric W. Biederman wrote:

> Last time I was looking at this I was noticing that there is a lock
> (mmap_sem?) that is held over every ->vm_op->foo() call.  If that is
> true today it should be possible to just grab that lock and change
> vm_ops.  That makes for a very cheap and easy implementation, except for
> the covolutions needed for taking the lock.

3-rd party down_write(&mm->mmap_sem) is a Bloody Bad Idea(tm).  VM locking is
complicated enough as it is and making it cope with such things would make it
even more convoluted.

> If we can do add useful support at the fs and mm layers without
> affecting performance I am all for it.  I remember that tends to make
> things easier.  As an alternative let me suggest what I had intended to
> do if/when I ever got back to working on revoke.
> 
> Make a library like libfs that can be used for files that want to
> implement revoke support.
> 
> In that library implement what can be implemented reliably and correctly
> and error on the sophisticated cases we can't support.
> 
> With the semantics and the basic users figured out move what bits we can
> into the vfs or the mm subsystem to make things easier.
> 
> With a library at the very least we have one implementation that we can
> debug and work with instead of a different implementation of revoke for
> each different kind of file.

Yecchh...  revoke() as a syscall or revoke as something that happens when
kernel decides that file has gone away?  The latter includes
procfs/debugfs/sysfs at the very least.  Do we want to require all of those
to use that library?  I would rather try to avoid a need for wrappers, TBH...

You have a very good point re ->close() - the locking conditions for it are
such that making revoke do it is extremely inconvenient.  IMO it means that
mmap should check for attempts to set ->vm_op on vma with non-NULL
->vm_file->f_revoke and fail if it runs into such.

      reply	other threads:[~2013-04-11 23:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-05  4:29 [RFC] revoke(2) and generic handling of things like remove_proc_entry() Al Viro
2013-04-05 19:56 ` Greg Kroah-Hartman
2013-04-05 20:51   ` Al Viro
2013-04-05 22:46     ` Greg Kroah-Hartman
2013-04-06  3:01 ` Hannes Frederic Sowa
2013-04-06  5:00 ` Al Viro
2013-04-11 20:48   ` Eric W. Biederman
2013-04-11 23:29     ` Al Viro [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=20130411232913.GC4068@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.com \
    --cc=tiwai@suse.de \
    --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.