Re: [PATCH review 11/11] mnt: Honor MNT_LOCKED when detaching mounts

[Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>]

On Wed, Jan 07, 2015 at 06:43:34PM +0000, Al Viro wrote:
> On Mon, Jan 05, 2015 at 02:46:27PM -0600, Eric W. Biederman wrote:
> > Modify umount(MNT_DETACH) to keep mounts in the hash table that are
> > locked to their parent mounts, when the parent is lazily unmounted.
> > In doing this invert the reference count so that the parent holds a
> > reference to the children instead of the children holding a reference
> > to the parent.
> > 
> > Then in mntput_no_expire detach the children and in cleanup_mnt mntput
> > the children and dput the dentry they were mounted on.
> > 
> > In __detach_mounts if there are any mounts that have been unmounted
> > but still are on the list of mounts of a mountpoint, detach those
> > mounts and schedule them to be mntput and their reference to the dentry
> > to be put when it becomes safe to sleep.
> 
> Explicit description of your new refcounting rules, please.

I really hate those path_put(&p->mnt_ex_mountpoint) in the resulting code...
Can you ever get to your mntput_children() with non-NULL ->mnt_ex_mountpoint.mnt
in one of the survivors?  Looks like it shouldn't be possible at all...

What's to prevent such a survivor (not contributing to the refcount of
parent, to be dropped when parent gets killed) in the child list of a parent
that is still normally mounted?  And what happens if it's hit again, in
addition to "what does /proc/mounts of the namespace the parent's in look
like"?