Re: umount() and NFS races in 2.4.26

From: Trond Myklebust
Date: Sat Jul 10 2004 - 16:41:31 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/