>>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, looking in the rename_files routine it has the exact same logic where
if namei returns fromnd where fromnd.ni_dvp == fromnd.ni_startdir and
returns an error condition vrele will be called twice on that vnode...

Perhaps I'll insert some debuging code.

							--Greg
>
>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