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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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()?
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers



[Index of Archives]     [Cgroups]     [Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux