Possible bug: detached mounts difficult to cleanup

Al Viro viro at ZenIV.linux.org.uk
Wed Jan 11 02:51:33 UTC 2017


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


More information about the Containers mailing list