Date: Thu, 10 Mar 2005 03:58:09 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: arch@freebsd.org, pete@isilon.com Subject: Cleaning up vgone. Message-ID: <20050310034922.Y20708@mail.chesapeake.net>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050310034922.Y20708>