[PATCH review 11/11] mnt: Honor MNT_LOCKED when detaching mounts

Al Viro 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
> NULL
> 	* 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 mailing list