Re: Cleaning up vgone.

From: Jeff Roberson (jroberson_at_chesapeake.net)
Date: 03/10/05

  • Next message: Ian Dowse: "Re: Cleaning up vgone." 
    Date: Thu, 10 Mar 2005 04:05:32 -0500 (EST)
To: arch@freebsd.org, pete@isilon.com

    On Thu, 10 Mar 2005, Jeff Roberson wrote:

    > I've run into a few vclean races and some related problems with VOP_CLOSE
    > not using locks. I've made some fairly major changes to the way vfs
    > handles vnode teardown in the process of fixing this. I'll summarize what
    > I've done here.
    >
    > The main problem with teardown was the two stage locking scheme involving
    > the XLOCK. I got rid of the XLOCK and simply require the vnode lock
    > throughout the whole operation. To accommodate this, VOP_INACTIVE,
    > VOP_RECLAIM, VOP_CLOSE, and VOP_REVOKE all require the vnode lock. As
    > does vgone().
    >
    > Prior to this, vgone() would set XLOCK and then do a LK_DRAIN to make
    > sure there were no callers waiting in VOP_LOCK so that they would always
    > see the VI_XLOCK and know that the vnode had changed identities. Now,
    > vgone sets XLOCK, and all lockers who use vget() and vn_lock() check for

    This should be "vgone sets VI_DOOMED" which now means "the vnode has been
    dissociated from it's filesystem".

    > VI_DOOMED before and after acquiring the vnode lock. To wait for the
    > transition to complete, you simply wait on the vnode lock.
    >
    > This really only required minor changes of the filesystems in the tree.
    > Most only required the removal of a VOP_UNLOCK in VOP_INACTIVE, and a few
    > acquired the lock in VOP_CLOSE to do operations which they otherwise could
    > not. There is one change to ffs and coda which inspect v_data in their
    > vop_lock routines. This is only safe with the interlock held, where
    > before the XLOCK would have protected v_data in the one case that could
    > lead to panic.
    >
    > The patch is available at http://www.chesapeake.net/~jroberson/vgone.diff
    >
    > Cheers,
    > Jeff
    > _______________________________________________
    > freebsd-arch@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
    >
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Ian Dowse: "Re: Cleaning up vgone."

    Relevant Pages

    • Re: ffs snapshot lockup
      ... If the buffer lock has waiters after the buffer has changed identity then ... struct buf_queue_head { ... retrieving revision 1.106 ... * is currently suspending/suspended and vnode has been accessed. ...
      (freebsd-stable)
    • Re: [PATCH] Make udf(4) MPSAFE and use shared lookups
      ... Set VV_ROOT in udf_vgetif we ever return a vnode instead of doing ... Allow lock recursion. ... Tracing pid 977 tid 100087 td 0xc43b4d80 ... lock type udf: EXCL by thread 0xc43b4d80 ...
      (freebsd-current)
    • Re: 6.0 hangs (while building OOo)
      ... >> I don't see any obvious lock leaks in the code. ... > Looks like the function returns with the desired leaf vnode locked if I ... Frame 15 and some of its variables might be interesting: ...
      (freebsd-current)
    • Re: Cleaning up vgone.
      ... > code was filesystems that used shared locks such as NFS, ... XLOCK was introduced because the vnode lock was not ... > original vnode wakes up and sees the VI_DOOMED flag? ...
      (freebsd-arch)
    • Re: How to find whats locking a file
      ... To free the file, use the CHKIN command. ... very big spool file. ... You are now looking at part of the vnode information for the file. ... scroll forward until you see the line containing only "Lock ...
      (comp.sys.ibm.as400.misc)