linux-fsdevel.vger.kernel.org archive mirror
 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,
	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*

  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).