Re: panic: mutex Giant owned at nfs_syscalls.c:556

From: Kris Kennaway <kris_at_FreeBSD.org>
Date: Thu, 21 Feb 2008 12:00:41 +0100
pluknet wrote:
> I got this assertion while attempting to remove file on nfs mounted
> ffs filesystem.
> NFS client on 7.0-PRERELEASE and NFS server on 8-CURRENT.
> 
> FreeBSD 7.0-PRERELEASE #1: Wed Feb  6 18:09:18 MSK 2008
> FreeBSD 8.0-CURRENT #9: Fri Feb 15 14:31:07 MSK 2008
> 
> Unread portion of the kernel message buffer:
> panic: mutex Giant owned at
> /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:556
> KDB: enter: panic
> exclusive sleep mutex nfsd_mtx r = 0 (0xc41d1660) locked _at_
> /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:501
> exclusive sleep mutex Giant r = 0 (0xc07e6410) locked _at_
> /usr/src/sys/kern/vfs_lookup.c:663
> ...
> #9  0xc053959d in panic (fmt=0xc076181d "mutex %s owned at %s:%d")
>     at /usr/src/sys/kern/kern_shutdown.c:555
> #10 0xc052adf7 in _mtx_assert (m=0xc07e6410, what=0,
>     file=0xc41cb7b2
> "/usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c",
> line=556) at /usr/src/sys/kern/kern_mutex.c:652
> #11 0xc41c9e82 in nfssvc (td=0xc2e68000, uap=0xd600dcfc)
>     at /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:556
> #12 0xc0727903 in syscall (frame=0xd600dd38)
>     at /usr/src/sys/i386/i386/trap.c:1034
> #13 0xc0711630 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:203
> ---Type <return> to continue, or q <return> to quit---
> #14 0x00000033 in ?? ()
> 
> Looks somewhat strange because nfs_syscalls.c:556 is not in nfssvc(),
> it's in nfssvc_nfsd().
> Kernel and world synchronized on 8-CUR though.
> 

This has been reported a couple of times before but you are the first to 
provide the WITNESS data, which was necessary to proceed.  Thanks :)

So there are two questions:

1) Why is Giant being acquired at all?  vfs_lookup.c:663 is a 
VFS_LOCK_GIANT indicating that you are doing a lookup on a non-mpsafe 
filesystem.  What filesystems are being exported by the server? 
Previously people claimed not to be exporting any filesystems that 
should be marked !mpsafe, which was a puzzle.

2) Missed VFS_UNLOCK_GIANT somewhere, or broken assert.  The above trace 
should be enough to diagnose though.

Kris
Received on Thu Feb 21 2008 - 10:00:46 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:27 UTC