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"? -- 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
