This is a discussion on Re: panic: mutex Giant owned at nfs_syscalls.c:556 - FreeBSD ; pluknet wrote: > On 21/02/2008, Kris Kennaway wrote: >> 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. ...
> On 21/02/2008, Kris Kennaway
>> 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
to continue, or q 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.
> I'm sorry for confusing you. :/ Actually 1 msdosfs filesystem is being exported.
> BTW panic occurred on UP kernel.
>> 2) Missed VFS_UNLOCK_GIANT somewhere, or broken assert. The above trace
>> should be enough to diagnose though.
> I will try to reproduce and investigate this (in a week).
Thanks, it makes sense that it should be acquiring Giant then.
* Whatever happened to the SoC project that was supposed to work on
* making msdosfs mpsafe?
Hopefully it should be a straightforward fix to track down which code
path is missing the VFS_UNLOCK_GIANT() to reach the above stack trace,
or to reproduce.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"