Subject: Re: bug kern/5026
To: Frank van der Linden <frank@wins.uva.nl>
From: Greg Wohletz <greg@duke.CS.UNLV.EDU>
List: current-users
Date: 05/06/1998 09:18:16
>On Tue, May 05, 1998 at 09:56:21AM -0700, Greg Wohletz wrote:
>> So the vnode that is pointed to by both fromnd.ni_dvp and fromnd.ni_startdir
>> is vrele'ed twice.  Unfortunately I don't really have a good understanding
>> of how this code works, so I could be completely off base.  I'm hoping that
>> someone who is familiar with this code can shed some light on what is
>> going on here.
>
>For lookup operations in the NetBSD NFS server code, ni_startdir
>being equal to ni_dvp is the common case, as NFS lookup operations
>are one-component only. The exception is the WebNFS case, but you
>are not using that. So I don't think that this is the problem here.
>
>It is, however, likely that something like this is causing your problem.
>Locks and references to vnodes around lookup operations is hairy
>business. I'd guess that there is some error causing an unusual path
>through all the if statements and referencing/locking to be taken.
>
>You said you were using quotas; perhaps the error occurs because
>a user has reached the quota limit.

That's possible, but I wouldn't expect a rename operation to effect a users
disk quota, and all the crashes I've gotten dumps of so far (7 as of this
morning) have paniced via the nfsrv_rename routine.  I also noted that
there were 2 other similar PR's on file regarding this panic (kern/4364 amd
lerm/5073), 4365 paniced via the rename_files routine.  So the problem
isn't specific to the nfs version of the rename if that helps anyone.

BTW, I've moved the crash dumps and kernels into
http://www.cs.unlv.edu/~greg/netbsd/ if anyone wants to look at them.


						--Greg