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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html