Cleaning up vgone.

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

  • Next message: Jeff Roberson: "Re: Cleaning up vgone." 
    Date: Thu, 10 Mar 2005 03:58:09 -0500 (EST)
To: arch@freebsd.org, pete@isilon.com

    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
    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"

  • Next message: Jeff Roberson: "Re: Cleaning up vgone."

    Relevant Pages

    • Re: Recurring problem: processes block accessing UFS file system
      ... > trace), so I traced each pid associated with a locked vnode separately. ... There appears to be a lock order reversal between a vnode lock and the ... the suspend lock while holding a vnode lock. ...
      (freebsd-stable)
    • Re: Linker deadlock.
      ... Linker can easly deadlock when we try to load the same kernel module ... already held vnode lock at this point. ... it seems that dropping the module' vnode lock around the call to ...
      (freebsd-hackers)
    • Re: kthreads->kproc and back to kthread.. next patch
      ... duplication of vmspaces for all off the kthreads that are currently ... lock and tried to acquire the vnode lock. ...
      (freebsd-current)
    • Re: kthreads->kproc and back to kthread.. next patch
      ... duplication of vmspaces for all off the kthreads that are currently ... lock and tried to acquire the vnode lock. ...
      (freebsd-current)
    • Re: Cleaning up vgone.
      ... > handles vnode teardown in the process of fixing this. ... I got rid of the XLOCK and simply require the vnode lock ... you simply wait on the vnode lock. ...
      (freebsd-arch)