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
next prev parent 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).