From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-fsdevel@vger.kernel.org,
Andrei Vagin <avagin@virtuozzo.com>,
Ram Pai <linuxram@us.ibm.com>
Subject: Re: [REVIEW][PATCH] mnt: Tuck mounts under others instead of creating shadow/side mounts.
Date: Thu, 12 Jan 2017 05:03:40 +0000 [thread overview]
Message-ID: <20170112050339.GR1555@ZenIV.linux.org.uk> (raw)
In-Reply-To: <87inplinxd.fsf@xmission.com>
On Thu, Jan 12, 2017 at 05:03:42AM +1300, Eric W. Biederman wrote:
> Al Viro <viro@ZenIV.linux.org.uk> writes:
>
> > On Wed, Jan 11, 2017 at 01:10:57PM +1300, Eric W. Biederman wrote:
> >> >> + if (child->mnt.mnt_root == smp->m_dentry) {
> >> >
> >> > Explain, please. In which case is that condition _not_ satisfied, and
> >> > what should happen i
> >>
> >> When a tree is grafted in that condition does not apply to the lower
> >> leaves of the tree. At the same time nothing needs to be done for those
> >> leaves. Only the primary mountpoint needs to worry about tucking.
> >
> > How in hell would those lower leaves end up on the list in
> > attach_recursive_mnt()? IDGI...
>
> The submounts of a mount tree that is being attached need to have
> commit_tree called on them to attach them to a mount namespace.
Huh? commit_tree() is called once for each copy of the source tree. This
list_add_tail(&head, &mnt->mnt_list);
list_for_each_entry(m, &head, mnt_list)
m->mnt_ns = n;
is what goes through submounts in each of them, _not_ the loop in the caller.
What we get out of propagate_mnt() is the list of copies of source tree,
one for each of the mountpoints that should get propagation from the
target.
->mnt_mountpoint/->mnt_parent is fully set for all nodes.
Everything except the roots of those trees is hashed and
has ->mnt_child set up.
->mnt_hash of the roots of those copies host the cyclic list,
anchored in tree_list passed to propagate_mnt().
->mnt_list in each copy forms an unanchored cyclic list
going through all mounts in that copy.
The loop in attach_recursive_mnt() takes the tree_list apart and for each
element (== each copy of source tree) we have commit_tree() called once,
doing the remaining work:
* splices the ->mnt_list into the namespace's mount list
* sets ->mnt_ns for all nodes (root and submounts alike)
* sets ->mnt_child and ->mnt_hash for the root.
Again, the loop in attach_recursive_mnt() is over the set of secondary
copies of the source tree; it goes *only* through their roots. Submounts
are seen only by commit_tree(), in the list_for_each_entry() loop in
that function. Hell, try to add else WARN_ON(1); to that if (...) of yours
and see if you can trigger it if you don't believe the above...
> > You have "if mount is not locked - mark it; if mount is already marked -
> > mark it again". The latter part (|| IS_MNT_MARKED(mnt), that is) looks
> > very odd, won't you agree? What the hell was that (its counterpart in
> > the earlier code) about?
>
> Not mark it again. If the parent is marked mark the child.
*doh*
next prev parent reply other threads:[~2017-01-12 5:04 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-31 4:10 [PATCH] Fix a race in put_mountpoint Krister Johansen
2016-12-31 6:17 ` Al Viro
2017-01-03 0:51 ` Eric W. Biederman
2017-01-03 1:48 ` Al Viro
2017-01-03 3:17 ` Eric W. Biederman
2017-01-03 4:00 ` Al Viro
2017-01-04 3:52 ` Eric W. Biederman
2017-01-04 3:53 ` [PATCH] mnt: Protect the mountpoint hashtable with mount_lock Eric W. Biederman
2017-01-04 21:04 ` [REVIEW][PATCH] mnt: Tuck mounts under others instead of creating shadow/side mounts Eric W. Biederman
2017-01-07 5:06 ` Al Viro
2017-01-11 0:10 ` Eric W. Biederman
2017-01-11 4:11 ` Al Viro
2017-01-11 16:03 ` Eric W. Biederman
2017-01-11 16:18 ` [REVIEW][PATCH 1/2] mnt: Fix propagate_mount_busy to notice all cases of busy mounts Eric W. Biederman
2017-01-11 16:19 ` [REVIEW][PATCH 2/2] mnt: Tuck mounts under others instead of creating shadow/side mounts Eric W. Biederman
2017-01-12 5:45 ` Al Viro
2017-01-20 7:20 ` Eric W. Biederman
2017-01-20 7:26 ` [PATCH v5] " Eric W. Biederman
2017-01-21 3:58 ` Ram Pai
2017-01-21 4:15 ` Eric W. Biederman
2017-01-23 19:02 ` Ram Pai
2017-01-24 0:16 ` Eric W. Biederman
2017-02-03 10:54 ` Eric W. Biederman
2017-02-03 17:10 ` Ram Pai
2017-02-03 18:26 ` Eric W. Biederman
2017-02-03 20:28 ` Ram Pai
2017-02-03 20:58 ` Eric W. Biederman
2017-02-06 3:25 ` Andrei Vagin
2017-02-06 21:40 ` Ram Pai
2017-02-07 6:35 ` Andrei Vagin
2017-01-12 5:30 ` [REVIEW][PATCH 1/2] mnt: Fix propagate_mount_busy to notice all cases of busy mounts Al Viro
2017-01-20 7:18 ` Eric W. Biederman
2017-01-13 20:32 ` Andrei Vagin
2017-01-18 19:20 ` Andrei Vagin
2017-01-20 23:18 ` Ram Pai
2017-01-23 8:15 ` Eric W. Biederman
2017-01-23 17:04 ` Ram Pai
2017-01-12 5:03 ` Al Viro [this message]
2017-05-14 2:15 ` [REVIEW][PATCH] mnt: Tuck mounts under others instead of creating shadow/side mounts Andrei Vagin
2017-05-14 4:05 ` Eric W. Biederman
2017-05-14 9:26 ` Eric W. Biederman
2017-05-15 18:27 ` Andrei Vagin
2017-05-15 19:42 ` Eric W. Biederman
2017-05-15 20:10 ` [REVIEW][PATCH] mnt: In umount propagation reparent in a separate pass Eric W. Biederman
2017-05-15 23:12 ` Andrei Vagin
2017-05-16 5:42 ` [PATCH] test: check a case when a mount is propagated between exiting mounts Andrei Vagin
2017-05-17 5:54 ` [REVIEW][PATCH 1/2] mnt: In propgate_umount handle visiting mounts in any order Eric W. Biederman
2017-05-17 5:55 ` [REVIEW][PATCH 2/2] mnt: Make propagate_umount less slow for overlapping mount propagation trees Eric W. Biederman
2017-05-17 22:48 ` Andrei Vagin
2017-05-17 23:26 ` Eric W. Biederman
2017-05-18 0:51 ` Andrei Vagin
2017-05-24 20:42 ` [REVIEW][PATCH 1/2] mnt: In propgate_umount handle visiting mounts in any order Ram Pai
2017-05-24 21:54 ` Eric W. Biederman
2017-05-24 22:35 ` Ram Pai
2017-05-30 6:07 ` Ram Pai
2017-05-30 15:07 ` Eric W. Biederman
2017-06-07 9:54 ` Ram Pai
2017-06-07 13:09 ` Eric W. Biederman
2017-05-22 8:15 ` [REVIEW][PATCH] mnt: In umount propagation reparent in a separate pass Ram Pai
2017-05-22 18:33 ` Eric W. Biederman
2017-05-22 22:34 ` Ram Pai
2017-05-23 13:58 ` Eric W. Biederman
2017-01-06 7:00 ` [PATCH] mnt: Protect the mountpoint hashtable with mount_lock Krister Johansen
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=20170112050339.GR1555@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=avagin@virtuozzo.com \
--cc=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
/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).