Subject: Re: VNODE_LOCKDEBUG and VOP_READDIR
To: Gary Duzan <gary@duzan.org>
From: Antti Kantee <pooka@cs.hut.fi>
List: tech-kern
Date: 06/28/2007 14:44:17
On Thu Jun 28 2007 at 07:38:33 -0400, Gary Duzan wrote:
> In vnode_if.c:VOP_READDIR(), some ifdef(VNODE_LOCKDEBUG) code
> is trying to verify that the vnode is locked with LK_EXCLUSIVE,
> but vfs_vnops.c:vn_readdir() is locking it LK_SHARED, leading to:
>
> panic: vop_readdir: vp: locked 0, expected 1
> Stopped in pid 677.1 (ls) at netbsd:cpu_Debugger+0x5: leave
> db{1}> cpu_Debugger() at netbsd:cpu_Debugger+0x5
> panic() at netbsd:panic+0x1fc
> VOP_READDIR() at netbsd:VOP_READDIR+0x9f
> vn_readdir() at netbsd:vn_readdir+0xf7
> sys___getdents30() at netbsd:sys___getdents30+0xef
> syscall_plain() at netbsd:syscall_plain+0x1cf
> uvm_fault(0xffff80004e667db0, 0x0, 1) -> e
> kernel: page fault trap, code=0
>
> Is this a real problem or just an overzealous test? I would
> think a shared lock would be good enough, but I wanted to be sure
> before moving on with my debugging.
Overzealous test. Same for VOP_READ, actually. And speaking of that,
I guess we could use a shared lock for VOP_READLINK. Not that I expect
it to be a huge bottleneck.
But VNODE_LOCKDEBUG is known to not really work. Or, it works, but
parts of the system play it too fast & loose with the locking protocol.
I'm surprised you could even boot with VNODE_LOCKDEBUG.
--
Antti Kantee <pooka@iki.fi> Of course he runs NetBSD
http://www.iki.fi/pooka/ http://www.NetBSD.org/
"la qualité la plus indispensable du cuisinier est l'exactitude"