On Wed, 2017-12-06 at 12:33 +0000, Al Viro wrote: > On Wed, Dec 06, 2017 at 12:14:41PM +0000, Al Viro wrote: > > On Fri, Nov 17, 2017 at 11:45:47AM -0600, Joshua Watt wrote: > > > The umount_end operation allows cleaning of state set by > > > umount_begin in > > > the event the filesystem doesn't actually get unmounted. > > > > The locking doesn't make any sense. This thing can come at *any* > > moment - > > one process does this force-unmount of yours, another comes and > > accesses > > the damn thing just as you've decided that umount has failed and go > > to call that method. > > Consider, BTW, the situation when another umount -f comes just as > you've > dropped ->s_umount. Now your ->umount_end() comes *after* > ->umount_begin() > from the second call. Yes I realised that was a posibility, which is why the NFS implementation of this uses an atomic counter in ->umount_begin() and ->umount_end(). My line of thinking was that most fs drivers are probably going to ignore ->umount_end(), so it is only those that implement it that need to actually account for that problem. Or rather put, we can punt that problem to the FS driver writers if they choose to implement ->umount_end(). Maybe that isn't fair to the fs driver writers? Or maybe it just needs better documentation of that expectation? cc'ing linux-fsdevel@xxxxxxxxxxxxxxx, original message chain can be found here: http://www.spinics.net/lists/linux-nfs/msg66483.html Thanks, Joshua Watt -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
