[PATCH review 11/11] mnt: Honor MNT_LOCKED when detaching mounts
Eric W. Biederman
ebiederm at xmission.com
Wed Jan 7 19:30:22 UTC 2015
Al Viro <viro at ZenIV.linux.org.uk> 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.
More information about the Containers