From: Al Viro <viro@ftp.linux.org.uk>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linuxram@us.ibm.com
Subject: Re: [PATCH 12/18] shared mount handling: bind and rbind
Date: Wed, 9 Nov 2005 15:56:34 +0000 [thread overview]
Message-ID: <20051109155634.GY7992@ftp.linux.org.uk> (raw)
In-Reply-To: <E1EZrmJ-0001dI-00@dorka.pomaz.szeredi.hu>
On Wed, Nov 09, 2005 at 04:22:23PM +0100, Miklos Szeredi wrote:
> > On Wed, Nov 09, 2005 at 11:54:36AM +0100, Miklos Szeredi wrote:
> > > Shouldn't this check go before copy_tree()? Not much point in copying
> > > the tree if we are sure it won't be used.
> >
> > Incorrect. Propagation nodes further down the tree can very well be
> > mountable.
>
> Can you please give an example. I'm feeling thick.
>
> What I see in the code is that the the mount tree is copied, then put
> on the tmp_list, and at the end the newly copied tree is freed with
> umount_tree().
Before it gets freed it may end up being copied. Example: vfsmounts
A and B are peers, C is a slave of that peer group. It happens to be
on slave list of B. B has root deeper than A, which, in turn is deeper
than that of C (e.g. A and B had been created by binding subtrees of
C, which had been made slave afterwards). We bind on something in A,
outside of the subtree mapped by B.
Alternatively, have A -> (B, D) -> C, with C on slave list of B. Mountpoint
is within subtrees for A, C and D, but not B. And no, we can't say "skip B,
just make a slave of tree on A and slap it on C" - correct result is to
have T_A -> T_D -> T_C (i.e. tree on C gets propagation from tree on D).
Which kills the variants with not creating that copy and making subsequent
ones directly from the original tree.
next prev parent reply other threads:[~2005-11-09 15:56 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-08 2:01 [PATCH 12/18] shared mount handling: bind and rbind Al Viro
2005-11-08 14:11 ` Miklos Szeredi
2005-11-08 15:48 ` Ram Pai
2005-11-08 15:55 ` Miklos Szeredi
2005-11-09 18:44 ` Ram Pai
2005-11-09 18:59 ` Linus Torvalds
2005-11-09 19:26 ` Al Viro
2005-11-09 19:28 ` Ram Pai
2005-11-16 3:29 ` Rob Landley
2005-11-16 3:53 ` Linus Torvalds
2005-11-16 5:35 ` Al Boldi
2005-11-16 8:19 ` Miklos Szeredi
2005-11-16 9:10 ` Rob Landley
2005-11-16 10:14 ` Miklos Szeredi
2005-11-16 13:59 ` Shaya Potter
2005-11-16 16:35 ` Miklos Szeredi
2005-11-16 20:05 ` Al Boldi
2005-11-16 20:21 ` Shaya Potter
2005-11-16 8:47 ` Rob Landley
2005-11-16 8:41 ` Rob Landley
2005-11-16 16:18 ` Linus Torvalds
2005-11-09 10:54 ` Miklos Szeredi
2005-11-09 14:31 ` Al Viro
2005-11-09 15:22 ` Miklos Szeredi
2005-11-09 15:56 ` Al Viro [this message]
2005-11-09 16:33 ` Miklos Szeredi
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=20051109155634.GY7992@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=miklos@szeredi.hu \
--cc=torvalds@osdl.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.