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: Krister Johansen <kjlx@templeofstupid.com>,
	linux-fsdevel@vger.kernel.org,
	containers@lists.linux-foundation.org
Subject: Re: Possible bug: detached mounts difficult to cleanup
Date: Wed, 11 Jan 2017 02:51:33 +0000	[thread overview]
Message-ID: <20170111025132.GP1555@ZenIV.linux.org.uk> (raw)
In-Reply-To: <87fukqwcue.fsf@xmission.com>

On Wed, Jan 11, 2017 at 03:27:05PM +1300, Eric W. Biederman wrote:

> The design is for the parent mount to hold a reference to the submounts.
> And when the reference on the parent drops to 0.  The references on
> all of the submounts will also be dropped.

Parent does _not_ hold any references to submounts.  Never had.  What
happens in umount_tree() is that any surviving submounts
	a) are inserted into ->mnt_pins of parent, but not into unmounted.
	a) have the reference to parent dropped.

When the last reference to parent gets dropped, all remaining submounts
get unhashed and when we get to cleanup_mnt() on parent, ->mnt_pins
gets pulled.  Which does dput() on (ex)mountpoints and mntput() on
those submounts.

> I was hoping to read the code and point it out to you quickly, but I am
> not seeing it now.  I am wondering if in all of the refactoring of that
> code something was dropped/missed :(
> 
> Somewhere there is supposed to be the equivalent of:
> 	pin_insert_group(&p->mnt_umount, &p->mnt_parent->mnt, &unmounted);
> when we unhash those mounts because the last count has gone away.
> Either it is very sophisticated or I am missing it.  Grr....

What you are missing is that they never end up on 'unmounted' - only on
->mnt_pin of parent.  It's the same pin_insert_group() in umount_tree()
as for everything else, the only difference being that it does _not_
get kicked out on the namespace_unlock().

      parent reply	other threads:[~2017-01-11  2:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-11  1:24 Possible bug: detached mounts difficult to cleanup Krister Johansen
2017-01-11  2:04 ` Eric W. Biederman
2017-01-11  3:07   ` Krister Johansen
2017-01-13  0:37     ` Andrei Vagin
2017-01-13 23:28       ` Krister Johansen
2017-01-11  2:27 ` Eric W. Biederman
2017-01-11  2:37   ` Eric W. Biederman
2017-01-12  6:15     ` Krister Johansen
2017-01-12  8:26       ` Eric W. Biederman
2017-01-13 23:28         ` Krister Johansen
2017-01-11  2:51   ` Al Viro [this message]

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=20170111025132.GP1555@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=containers@lists.linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=kjlx@templeofstupid.com \
    --cc=linux-fsdevel@vger.kernel.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 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).