Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes: > 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. 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. As for how those mounts interact with copy_tree, they aren't designed to. I had overlooked that collect_mounts is weird and if the proper race exists can be called on an unmounted tree. So I expect the interaction with copy_tree is buggy. I will look at that and see what I can do to fix that (it shouldn't be hard). I expect I can just return an error if the mount has been unmounted. Eric -- 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
