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"