linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: trond.myklebust@fys.uio.no, dhowells@redhat.com,
	linuxram@us.ibm.com, viro@parcelfarce.linux.theplanet.co.uk,
	akpm@osdl.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fix race in mark_mounts_for_expiry()
Date: Wed, 18 May 2005 20:52:18 +0100	[thread overview]
Message-ID: <20050518195218.GA3051@mail.shareable.org> (raw)
In-Reply-To: <E1DYTri-0001SL-00@dorka.pomaz.szeredi.hu>

Miklos Szeredi wrote:
> > That makes less sense if we allow other tasks to be using a namespace
> > through a passing a file descriptor, and then the last task which has
> > current->namespace equal to that namespace exits.  It makes no sense
> > to me that the mount which is still accessible through the file
> > descriptor is suddenly detached from it's parent and children mounts.
> 
> I see your point.  I don't yet see a solution.
> 
> Currently detach is an explicit action, not something automatic which
> happens when there are no more references to a vfsmount.

It's implicit, when the last task calls put_namespace:

	void __put_namespace(struct namespace *namespace)
	{
[...]
		umount_tree(namespace->root);
		-> calls detach_mnt for each vfsmnt in namespace.
[...]
	}

> > Why is it not good enough to detach each vfsmnt when the last
> > reference to each vfsmnt is dropped?  In other words, simply when the
> > vfsmnt becomes unreachable?
> 
> Define unreachable.

Unreachable as in no file descriptors (or chroot/cwd) refer to the
vfsmnt, either directly or indirectly through a path traversal.

> Then define a mechanism, by which it can be detected.

There aren't any vfsmnt->vfsmnt cycles...  They're a forest, vfsmnts
don't move from one tree to another (bind mounts don't link them, they
create new vfsmnts), and each tree can be referenced by a file
descriptor at any point on the tree.

It rather hinges on which of these behaviours you prefer:

   1. A file descriptor/chroot/cwd reference to any point in a vfsmnt
      tree means the whole tree is retained.  This means ".." remains
      always accessible: fchdir(fd); open("..") continues to access
      that whole tree as you still have fd.

   2. A file descriptor/chroot/cwd reference to any point in a vfsmnt
      tree means the subtree from that point is retained, and parents
      may disappear if there are no references (not counting ".." as a
      reference).  This behaviour is more sensible for chroots, where
      the parents should be inaccessible anyway.

   3. A mixture, where current->root references only maintain the
      subtree rooted at that point, and other references, if outside
      the current->root subtree, retain the whole tree accessible from
      those references.

The appropriate data structure / algorithm depends on which behaviour
is preferred.  So which is it?  1 Is best done with a mnt_namespace
structure, but references to it counted when vfsmnts are referenced by
file descriptors/root/cwd, _not_ references by tasks (no
current->namespace).  2 is best done by simply reference counting
vfsmnts.

-- Jamie

  reply	other threads:[~2005-05-18 19:52 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-13 10:44 [PATCH] namespace.c: fix bind mount from foreign namespace Miklos Szeredi
2005-05-13 16:49 ` Ram
2005-05-13 17:06 ` Al Viro
2005-05-13 17:17   ` Miklos Szeredi
2005-05-13 17:25     ` Al Viro
2005-05-13 17:34       ` Miklos Szeredi
2005-05-13 17:29     ` Ram
2005-05-13 18:40       ` Miklos Szeredi
     [not found]         ` <1116012287.6248.410.camel@localhost>
     [not found]           ` <E1DWfqJ-0004eP-00@dorka.pomaz.szeredi.hu>
     [not found]             ` <1116013840.6248.429.camel@localhost>
2005-05-14  6:11               ` Miklos Szeredi
2005-05-16 15:11                 ` Ram
2005-05-16  8:44                   ` Miklos Szeredi
2005-05-16  8:59                     ` Miklos Szeredi
2005-05-16 11:26                     ` Jamie Lokier
2005-05-16 13:23                       ` Miklos Szeredi
2005-05-16 11:14                   ` Jamie Lokier
2005-05-17  3:50                     ` Ram
2005-05-16 20:15                       ` Miklos Szeredi
2005-05-17  1:28                         ` Jamie Lokier
2005-05-17  5:34                           ` Miklos Szeredi
     [not found]                             ` <1116360352.24560.85.camel@localhost>
     [not found]                               ` <E1DYI0m-0000K5-00@dorka.pomaz.szeredi.hu>
     [not found]                                 ` <1116399887.24560.116.camel@localhost>
     [not found]                                   ` <1116400118.24560.119.camel@localhost>
2005-05-18  9:51                                     ` [PATCH] fix race in mark_mounts_for_expiry() Miklos Szeredi
2005-05-18 10:32                                     ` David Howells
2005-05-18 10:37                                       ` Miklos Szeredi
2005-05-18 10:46                                       ` David Howells
2005-05-18 10:53                                         ` Miklos Szeredi
2005-05-18 11:07                                           ` Trond Myklebust
2005-05-18 11:32                                             ` Miklos Szeredi
2005-05-18 12:50                                               ` Jamie Lokier
2005-05-18 13:21                                                 ` Miklos Szeredi
2005-05-18 17:34                                                   ` Jamie Lokier
2005-05-18 19:05                                                     ` Miklos Szeredi
2005-05-18 19:52                                                       ` Jamie Lokier [this message]
2005-05-19 12:41                                                         ` Miklos Szeredi
2005-05-18 10:59                                         ` David Howells
2005-05-18 11:14                                           ` Miklos Szeredi
2005-05-18 11:51                                         ` David Howells
2005-05-18 12:08                                           ` Miklos Szeredi
2005-05-18 12:33                                             ` Miklos Szeredi
2005-05-18 16:53                                               ` Miklos Szeredi
2005-05-18 18:47                                                 ` Ram
2005-05-18 19:19                                                   ` Miklos Szeredi
2005-05-18 20:35                                                     ` Ram
2005-05-19 12:52                                                       ` Miklos Szeredi
2005-05-17 18:48                         ` [PATCH] namespace.c: fix bind mount from foreign namespace Ram
2005-05-17  0:00                       ` Jamie Lokier

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=20050518195218.GA3051@mail.shareable.org \
    --to=jamie@shareable.org \
    --cc=akpm@osdl.org \
    --cc=dhowells@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=miklos@szeredi.hu \
    --cc=trond.myklebust@fys.uio.no \
    --cc=viro@parcelfarce.linux.theplanet.co.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).