Date: Thu, 21 Feb 2008 12:00:41 +0100 From: Kris Kennaway <kris@FreeBSD.org> To: pluknet <pluknet@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: panic: mutex Giant owned at nfs_syscalls.c:556 Message-ID: <47BD59D9.9010308@FreeBSD.org> In-Reply-To: <a31046fc0802200328i31833093i15ac0db5e764b40a@mail.gmail.com> References: <a31046fc0802200328i31833093i15ac0db5e764b40a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 @ > /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:501 > exclusive sleep mutex Giant r = 0 (0xc07e6410) locked @ > /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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47BD59D9.9010308>