Re: umount() and NFS races in 2.4.26

[Trond Myklebust]

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/