In Message <20070628114417.GD25400@cs.hut.fi> ,
   Antti Kantee <pooka@cs.hut.fi> wrote:

=>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:
=>> 
=>> [ ... ]
=>> 
=>>    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.

   Ok, I'll take it out of the kernel. Thanks.

   Just out of curiosity, are there plans to clean up and/or remove
VNODE_LOCKDEBUG? I'm just thinking about the next person who stumbles
on it, and anyone else having to read the code around it.

   I'm guessing the trick to booting with VNODE_LOCKDEBUG is to
run with an LFS root. The problem I'm trying to debug is related
to locking in LFS (probably fsync related), so I was grasping for
any debug information which might help.

					Gary Duzan