From owner-cvs-src@FreeBSD.ORG  Wed Aug 10 16:56:58 2005
Return-Path: <owner-cvs-src@FreeBSD.ORG>
X-Original-To: cvs-src@FreeBSD.org
Delivered-To: cvs-src@FreeBSD.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id BF08116A41F;
	Wed, 10 Aug 2005 16:56:58 +0000 (GMT)
	(envelope-from truckman@FreeBSD.org)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id B3D6043D64;
	Wed, 10 Aug 2005 16:56:57 +0000 (GMT)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j7AGukPP000662;
	Wed, 10 Aug 2005 09:56:50 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200508101656.j7AGukPP000662@gw.catspoiler.org>
Date: Wed, 10 Aug 2005 09:56:46 -0700 (PDT)
From: Don Lewis <truckman@FreeBSD.org>
To: kris@obsecurity.org
In-Reply-To: <20050810133048.GA54603@xor.obsecurity.org>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
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
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Aug 2005 16:56:58 -0000

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