Date: 02 Feb 2002 20:22:04 +0100 From: Dag-Erling Smorgrav <des@ofug.org> To: Kirk McKusick <mckusick@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_subr.c Message-ID: <xzpg04jheoz.fsf@flood.ping.uio.no> In-Reply-To: <200202020149.g121nJI67647@freefall.freebsd.org> References: <200202020149.g121nJI67647@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kirk McKusick <mckusick@FreeBSD.org> writes: > Log: > In the routines vrele() and vput(), we must lock the vnode and > call VOP_INACTIVE before placing the vnode back on the free list. > Otherwise there is a race condition on SMP machines between > getnewvnode() locking the vnode to reclaim it and vrele() > locking the vnode to inactivate it. This window of vulnerability > becomes exaggerated in the presence of filesystems that have > been suspended as the inactive routine may need to temporarily > release the lock on the vnode to avoid deadlock with the syncer > process. I think this might be the cause of the panic some people saw in procfs a couple of months ago; getvnode() would sometimes return a vnode that had already been reclaimed, and fstatfs() would dereference a NULL pointer. This was "fixed" by adding an extra check to fstatfs() in rev 1.216 of vfs_syscalls.c; this check is probably unnecessary now. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpg04jheoz.fsf>