Linux Container Development
 help / color / mirror / Atom feed
From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Krister Johansen
	<kjlx-6woCzk5+qv5TrMCiz+cRkdBPR1lH4CV8@public.gmane.org>
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Subject: Re: Possible bug: detached mounts difficult to cleanup
Date: Wed, 11 Jan 2017 15:37:36 +1300	[thread overview]
Message-ID: <87shoqtj7z.fsf@xmission.com> (raw)
In-Reply-To: <87fukqwcue.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> (Eric W. Biederman's message of "Wed, 11 Jan 2017 15:27:05 +1300")

ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) writes:

> Krister Johansen <kjlx-6woCzk5+qv5TrMCiz+cRkdBPR1lH4CV8@public.gmane.org> writes:
>
>> Gents,
>>
>> I wondered if a naive solution could re-walk the list of mounts
>> processed in umount_tree() and if all of the detached but locked mounts
>> had a refcount that indicated they're unused, they could be unlocked and
>> unmounted.  At least in the case of the containers I'm dealing with, the
>> the container software should be ensuring that nothing in the container
>> has a reference on anything that's under the detached portion of the
>> tree.  However, there's probably a better way to do this.
>
> So if the code is working correctly that should already happen.
>
> 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.
>
> 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....

Ok.  I see the code now, and it should be doing the right thing.

During umount_tree the code calls pin_insert_group(...) with the
last paramenter being NULL.  That adds the mount to one or two
lists.  The mnt_pins list of the parent mount and the &unmounted
hlist.

Then later when the parent's cleanup_mnt is called if the mnt_pins
still has entries mnt_pin_kill is called.  For every mount on the
mnt_pins list drop_mountpoint is called.  Which calls dput and
mntput.

So that is how your references are supposed to be freed.  Which leaves
the question why aren't your mounts being freed?  Is a file descriptor
perhaps from a mmaped executable holding a mount reference?

Perhaps you want to manually unmount everything and see if unmount will
fail on some mount and let you see which mount has a reference to it.

Eric

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

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170111012454.GB2497@templeofstupid.com>
     [not found] ` <20170111012454.GB2497-6woCzk5+qv5TrMCiz+cRkdBPR1lH4CV8@public.gmane.org>
2017-01-11  2:04   ` Possible bug: detached mounts difficult to cleanup Eric W. Biederman
     [not found]     ` <87r34a5p3t.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-01-11  3:07       ` Krister Johansen
     [not found]         ` <20170111030753.GC2497-6woCzk5+qv5TrMCiz+cRkdBPR1lH4CV8@public.gmane.org>
2017-01-13  0:37           ` Andrei Vagin
     [not found]             ` <CANaxB-zMzS-euqR1_LvZSoEsO-Y6q=_qGNTJZCKZTL5WfFF16g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-01-13 23:28               ` Krister Johansen
2017-01-11  2:27   ` Eric W. Biederman
     [not found] ` <87fukqwcue.fsf@xmission.com>
     [not found]   ` <87fukqwcue.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-01-11  2:37     ` Eric W. Biederman [this message]
     [not found]       ` <87shoqtj7z.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-01-12  6:15         ` Krister Johansen
     [not found]           ` <20170112061539.GA2345-6woCzk5+qv5TrMCiz+cRkdBPR1lH4CV8@public.gmane.org>
2017-01-12  8:26             ` Eric W. Biederman
     [not found]               ` <87r348y98z.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-01-13 23:28                 ` Krister Johansen
2017-01-11  2:51     ` Al Viro
2017-01-11  1:24 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=87shoqtj7z.fsf@xmission.com \
    --to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=kjlx-6woCzk5+qv5TrMCiz+cRkdBPR1lH4CV8@public.gmane.org \
    --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.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