From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 19:28:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 043D816A402 for ; Thu, 21 Feb 2008 19:28:57 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 34C8E13C45D; Thu, 21 Feb 2008 19:28:56 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BDD0F4.8020604@FreeBSD.org> Date: Thu, 21 Feb 2008 20:28:52 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: pluknet References: <47BD59D9.9010308@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: panic: mutex Giant owned at nfs_syscalls.c:556 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 19:28:57 -0000 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. >> > >> > 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. Kris