On Thu, Jan 08, 2015 at 03:02:29AM +0000, Al Viro wrote: > 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()? I really don't like the look of __detach_mounts() after those changes. Suppose we have a single "locked-and-lazy" vfsmount mounted on that dentry. With nothing mounted under it. Your loop will do absolutely nothing to it - it'll just keep spinning. Why are you doing anything to the stuff mounted under than one, anyway? It's this sucker you want to detach and kill... Normal case (umount_tree()) will detach the vfsmount we are giving it; this one should have the same effect... -- 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
