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 01:30:22PM -0600, Eric W. Biederman wrote:

> > Explicit description of your new refcounting rules, please.  What's more,
> > how do those non-pinning children interact with e.g. copy_tree()?
> 
> The parents hold a reference on the children, and the parent keeps track
> of it's children through the mnt_mounts list.  The parents reference to
> a child is held until the final mntput of the parent.

This is obvious crap.  It doesn't match the resulting code, not to mention
making no sense whatsoever.

If you (with your resulting tree) mount ten filesystems on /tmp/[0-9],
you will have refcount of vfsmount on /tmp incremented by 10.  Moreover,
you really don't want /tmp *not* to be busy after having done that.

The current rules are
	* take the number of external references
	* add 1 if it's reachable from hash table
with mnt->mnt_parent being a counting reference unless it points to mnt
itself.
One extra wart is namespace_unlock() treatment of ex-mountpoints - we
have decremented their refcounts early (during umount_tree()) to avoid
false positives on "is it busy" checks, but once we are done with calculating
the set of victims we want proper ordering on the fs shutdown vs dput() of
mountpoints, so namespace_unlock() starts with unrolling these decrements
and then replays them in proper order.

You have modified that, but your description above doesn't match what you
are doing.  Moreover, in absense of those locked-and-lazy you *still* have
the same rules as before.  Full description of the new rules, please.