From owner-freebsd-current@FreeBSD.ORG  Sun Jun  1 02:43:57 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 D5F7937B401
	for <current@FreeBSD.org>; Sun,  1 Jun 2003 02:43:57 -0700 (PDT)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 19A3D43FEA
	for <current@FreeBSD.org>; Sun,  1 Jun 2003 02:42:37 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.12.9/8.12.9) with ESMTP id h519gUM7003542
	for <current@FreeBSD.org>; Sun, 1 Jun 2003 02:42:34 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200306010942.h519gUM7003542@gw.catspoiler.org>
Date: Sun, 1 Jun 2003 02:42:30 -0700 (PDT)
From: Don Lewis <truckman@FreeBSD.org>
To: current@FreeBSD.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Subject: vnode locking problem in pseudofs/procfs
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: Sun, 01 Jun 2003 09:43:58 -0000

I just stumbled across this vnode locking problem in procfs()

db> tr
Debugger(c05215d4,c0520b94,c669b000,c0521615,e6d77764) at Debugger+0x54
vfs_badlock(c0521615,c0520b94,c669b000,c05b4340,c669b000) at vfs_badlock+0x45
assert_vop_locked(c669b000,c0520b94,c0520adf,358,c6a35400) at assert_vop_locked+
0x62
vn_fullpath(c66ce390,c669b000,e6d777a8,e6d777ac,c04ea6fb) at vn_fullpath+0xbc
procfs_doprocfile(c66ce390,c61c2960,c6272000,e6d777d4,0) at procfs_doprocfile+0x
3a
pfs_readlink(e6d77c10,c05210fd,c05b49c0,c6b2e920,e6d77c94) at pfs_readlink+0x116
VOP_READLINK(c6b2e920,e6d77c94,c6911d80,bfbed240,400) at VOP_READLINK+0x59
kern_readlink(c66ce390,bfbed650,0,bfbed240,0) at kern_readlink+0xc1
readlink(c66ce390,e6d77d10,c0535a6a,3fb,3) at readlink+0x38
syscall(2f,2f,2f,8134400,bfbedfd0) at syscall+0x26e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (58, FreeBSD ELF32, readlink), eip = 0x8058a73, esp = 0xbfbed21c, eb
p = 0xbfbeda68 ---


when I ran
	find / -print0 | xargs -0 ls -l
with the DEBUG_VFS_LOCKS kernel option.

The obvious part of the fix is to lock the vnode in procfs_doprocfile()
before calling vn_fullpath().  The more interesting question is if this
means that all callers of (pn->pn_func)() need to drop their vnode locks
in order to prevent a potential deadlock.  It looks to me like this is
necessary ...