Date: Wed, 10 Aug 2005 09:56:46 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: kris@obsecurity.org Cc: kan@FreeBSD.org, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_subr.c Message-ID: <200508101656.j7AGukPP000662@gw.catspoiler.org> In-Reply-To: <20050810133048.GA54603@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10 Aug, Kris Kennaway wrote:
> On Wed, Aug 10, 2005 at 11:46:03AM +0000, Alexander Kabaev wrote:
>> kan 2005-08-10 11:46:03 UTC
>>
>> FreeBSD src repository
>>
>> Modified files:
>> sys/kern vfs_subr.c
>> Log:
>> Do not drop the vnode interlock if vdropl is called on already doomed vnode.
>> vdropl callers expect it to return with interlock still being held.
>
> Does this fix panics some of us have been reporting?
It should get rid if the "lock (sleep mutex) vnode interlock not locked"
panic, but there is still a race condition in vlrureclaim(), which tests
this condition
if ((vp->v_iflag & VI_DOOMED) != 0 || vp->v_usecount ||
!LIST_EMPTY(&(vp)->v_cache_src) || (vp->v_object != NULL &&
vp->v_object->resident_page_count > trigger)) {
before obtaining the vnode lock. When vlrureclaim() calls VOP_LOCK() to
obtain the vnode lock, VOP_LOCK() drops the vnode interlock before it
obtains the vnode lock, so it is possible for these conditions to change
while waiting for the vnode lock or before the vnode interlock is
grabbed again. I suspect that losing this race could have other
implications ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508101656.j7AGukPP000662>