[PATCH review 11/11] mnt: Honor MNT_LOCKED when detaching mounts
viro at ZenIV.linux.org.uk
Thu Jan 8 03:02:29 UTC 2015
On Thu, Jan 08, 2015 at 12:22:27AM +0000, Al Viro wrote:
> Not sure if I like the use of mnt_child between mntput_no_expire() and
> cleanup_mnt() - it's probably safe, but the fewer lists we modify outside of
> mount hash lock, the better; hell knows, I'll need to stare at that code
> a bit more. FWIW, AFAICS the refcount rules with your variant are
> * external references countribute
> * mnt_parent contributes unless it points to ourselves *or* mnt_ns is
> * reachable from mount hash => add 1
> * in addition to the wart around namespace_unlock(), we have a similar
> wart between mntput_no_expire() and cleanup_mnt(), only there we thread the
> suckers on mnt_child instead of mnt_list and use slightly different logics to
> prevent shutdown of parent fs before the dput(mountpoint).
BTW, why do you use detach_mnt() in __detach_mounts()? Unless I'm missing
something really subtle, __detach_mnt() is the right thing there...
And while we are at it, all other callers of detach_mnt() are followed by
attach_mnt() within the same namespace *and* all attach_mnt() follow
detach_mnt(). So why bother with mnt_list in either? Or, put it
another way, why have __detach_mnt() separate from detach_mnt()?
More information about the Containers