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()? -- 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
