On Tue, Jan 25, 2005 at 04:09:52PM -0800, Bill Studenmund wrote:
> [...]
> Maybe. If it is, the following patch should fix things. I printed out 
> lookup() and stared at all the error cases. This fix is the only one I 
> found we need, and we need it strongly. :-)
> 
> The only other questionable case I found should be fine with the correct 
> input flags. The case was that the goto terminal just above dirloop: could 
> get to bad2 with ni_dvp unset. However we would have to be on a RO fs and 
> (more importantly) be performing a DELETE or RENAME op with both 
> LOCKPARENT and WANTPARENT unset. The latter shouldn't happen.
> 
> As an aside, it might be interesting to put a diagnostic printf() in the 
> new conditional. If the printf() fires, we know we found the issue.

Hi,
after about a week of compiles, I got this on the console:
Feb  4 03:21:24 folk /netbsd: vnode: table is full - increase kern.maxvnodes or NVNODE
Feb  4 03:21:24 folk last message repeated 135 times
Feb  5 07:27:11 lookup(): PDIRUNLOCK
folk /netbsd: vnode: table is full - increase kern.maxvnodes or NVNODE
Feb  5 07:27:12 folk last message repeated 2 times

The box didn't panic, but I can't log in. Lots of processes blocked on
vnlock. I have null mounts on this box (for the bulk build), with nullfs
loaded via LKM, maybe this is the reason. I've got a core dump from ddb.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--