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
next prev 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