Re: umount() and NFS races in 2.4.26

From: Trond Myklebust (trond.myklebust_at_fys.uio.no)
Date: 07/10/04

  • Next message: Byron Stanoszek: "[OOPS] 2.6.7 random oops in free_block()" 
    To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
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/

  • Next message: Byron Stanoszek: "[OOPS] 2.6.7 random oops in free_block()"

    Relevant Pages

    • Re: 2.4.23pre6aa1
      ... Talked with Trond and he has other fixes pending... ... > doesn't apply cleanly let me know and I can fix it for you. ... Apart from this there's a huge pile of fixes all over in -aa. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: NFS regression in 2.6
      ... > whitespace damage): ... That should fix it... ... Trond ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Power Management Update
      ... I encountered this problem by having an IDE CD-ROM, ... He mentioned producing a cleaner patch, but this should at least fix the ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] fs/fcntl.c : dont test unsigned value for less than zero
      ... I think the real problem here is that 'arg' ... architecture's ptrace code could easily make use of the latter, ... But be careful not to "fix up" ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Testing RC kernels [KORG]
      ... Can someone with access to the html for kernel.org please fix that? ... We've had several messages now complaining about this. ... Copyright 2005 by Maurice Eugene Heskett, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)