Date: Sat, 2 Feb 2002 18:13:41 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Kirk McKusick <mckusick@FreeBSD.ORG> Cc: "Jacques A. Vidrine" <n@nectar.cc>, Dag-Erling Smorgrav <des@ofug.org>, se@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern vfs_subr.c Message-ID: <200202030213.g132DfZ41859@apollo.backplane.com> References: <200202020149.g121nJI67647@freefall.freebsd.org> <xzpg04jheoz.fsf@flood.ping.uio.no> <20020202132721.A65496@hellblazer.nectar.cc>
next in thread | previous in thread | raw e-mail | index | archive | help
Kirk, is this something I should MFC? It looks like it could effect
-stable as well.
This bug looks like it has been present since 1997.
-Matt
:On Sat, Feb 02, 2002 at 08:22:04PM +0100, Dag-Erling Smorgrav wrote:
:> 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.
:...
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?200202030213.g132DfZ41859>