rwatson at FreeBSD.org
Tue Sep 27 14:32:02 PDT 2005
On Tue, 27 Sep 2005, Rob Watt wrote:
> this is the piece of code that was referenced by the ip:
> (gdb) l *0xffffffff803b88ca
> 0xffffffff803b88ca is in nfsrv_lookup (/usr/src/sys/nfsserver/nfs_serv.c:670).
> 665 NFSD_UNLOCK();
> 666 mtx_lock(&Giant); /* VFS */
> 667 if (dirp)
> 668 vrele(dirp);
> 669 NDFREE(&nd, NDF_ONLY_PNBUF);
> 670 if (ndp->ni_startdir)
> 671 vrele(ndp->ni_startdir);
> 672 if (ndp->ni_vp)
> 673 vput(ndp->ni_vp);
> 674 mtx_unlock(&Giant); /* VFS */
> we are not running nfsd (although we do use nfs and nfsiod), and none of
> our processes should have been accessing nfs. Our processes are run from
> an nfs mount but do not access any nfs mounted files.
That code is in the NFS server lookup code, so should be called as a
result of a lookup by a remote client. If the NFS server is not in use on
the machine, this is most likely this is a quirk of gdb and instruction
pointers, a run-time kernel/compile-time kernel mismatch, or something
really nasty. ndp should really never be NULL there, as it's used
frequently prior to that point. Let's hope for one of the former few
>> Do you have a testbed or set of test hosts set up so you can
>> non-disruptively test change sets, btw?
> yes we have 3 dual dual-core machines and 1 dual single-core machine
> that we can use to test with.
Great. As mentioned I'll be offline for about the next 48 hours, but back
after then. If we can get a nice clean crash out of this, would really be
best. If it's top panicking, it could well be due to a bug in the process
monitoring code, in kern_proc. We've run into bugs a few times there in
the past, generally associated with threading or races in process
creation/teardown, in which partially initialized (or torn down) processes
are accessed by another thread and are in an unexpected state.
Robert N M Watson
More information about the freebsd-amd64