From owner-freebsd-current@FreeBSD.ORG  Fri Dec 12 10:35:48 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 5766316A4CE
	for <freebsd-current@FreeBSD.org>;
	Fri, 12 Dec 2003 10:35:48 -0800 (PST)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 02E9943D33
	for <freebsd-current@FreeBSD.org>;
	Fri, 12 Dec 2003 10:35:46 -0800 (PST)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id hBCIZZeF058658;
	Fri, 12 Dec 2003 10:35:41 -0800 (PST)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200312121835.hBCIZZeF058658@gw.catspoiler.org>
Date: Fri, 12 Dec 2003 10:35:35 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
To: kuriyama@imgsrc.co.jp
In-Reply-To: <7mwu9217j0.wl@black.imgsrc.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
cc: freebsd-current@FreeBSD.org
Subject: Re: vn_fullpath: 0xc85e24a0 is not locked but should be
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Dec 2003 18:35:48 -0000

On 12 Dec, Jun Kuriyama wrote:
> At Thu, 11 Dec 2003 23:14:50 -0500 (EST),
> Robert Watson wrote:
>> Ah, you're still runing with the VFS lock debugging :-).  Indeed, it looks
>> like a vn_lock() and unlock of p->p_textvp is missing in
>> procfs_doprocfile(), even though that likely would violate the VFS lock
>> order.  The attached (untested) patch might well fix it, but might not be
>> right -- I'm not sure that curthread holds a valid reference to
>> p->p_textvp that can't evaporate during these operations.  I'm not sure
>> the proc reference stuff protects us properly here, but John would know
>> (CC'd). 
>> 
>> Index: procfs.c
>> ===================================================================
>> RCS file: /home/ncvs/src/sys/fs/procfs/procfs.c,v
>> retrieving revision 1.9
>> diff -u -r1.9 procfs.c
>> --- procfs.c	17 Apr 2003 22:12:12 -0000	1.9
>> +++ procfs.c	12 Dec 2003 04:13:10 -0000
>> @@ -70,7 +70,9 @@
>>  	char *fullpath = "unknown";
>>  	char *freepath = NULL;
>>  
>> +	vn_lock(p->p_textvp, LK_EXCLUSIVE | LK_RETRY, td);
>>  	vn_fullpath(td, p->p_textvp, &fullpath, &freepath);
>> +	VOP_UNLOCK(p->p_textvp, 0, td);
>>  	sbuf_printf(sb, "%s", fullpath);
>>  	if (freepath)
>>  		free(freepath, M_TEMP);
> 
> Okay, I'll wait without DEBUG_VFS_LOCKS until fix is committed.

DEBUG_VFS_LOCKS is quite usable as long as you don't run find, tar, etc.
that traverses procfs.