Messages in this thread | | | Subject | Re: umount() and NFS races in 2.4.26 | From | Trond Myklebust <> | Date | Sat, 10 Jul 2004 16:38:48 -0500 |
| |
På fr , 09/07/2004 klokka 09:32, skreiv Marcelo Tosatti: > > - The NFS async unlink code (fs/nfs/unlink.c) does keep a dentry for > > later asynchronous processing, but the mount point is unbusied via > > path_release() once sys_unlink() returns (fs/namei.c). While it > > does a dget() on the dentry, this is insufficient to prevent an > > umount(); when one would happen in the right time window, it seems > > that it would initially get past the busy check: > > if (atomic_read(&mnt->mnt_count) == 2 || flags & MNT_DETACH) { > > (fs/namespace.c, do_umount()), but invalidate_inodes() in kill_super() > > (fs/super.c) would then fail because of the inode referenced from > > the dentry needed for the async unlink (which cannot be removed > > by shrink_dcache_parent() because the NFS code did dget() it). > > > > Please note that this problem is only conjectured, as it turned out > > to not be our culprit. It looks not completely trivial to fix to me, > > I believe it might require some changes that would affect other FS > > implementations. It is not a true SMP race, if it exists it would > > affect UP systems as well. > > Trond?
Known problem, but a fix is not trivial since the unlink() procedure does not take a nameidata structure argument (which would be needed in order to figure out which vfs_mount struct to mntget()).
If someone can figure out a way to fix it, then a patch would be welcome, but I'm on holiday until the Linux Kernel Summit starts, so don't expect any immediate action from me...
Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |