Date: Wed, 28 May 2003 11:21:51 -0400 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: mb alloc and: panic: mutex Giant not owned at ../../../vm/vm_kern.c:315 Message-ID: <20030528152151.GA54501@unixdaemons.com> In-Reply-To: <Pine.NEB.3.96L.1030528095854.51795A-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1030528095854.51795A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 28, 2003 at 10:06:14AM -0400, Robert Watson wrote: > > Got this panic recently on a MAC development box. The MAC development > branch hasn't been integrated in a few weeks, so this might well be fixed > in the main tree. The versions of various files are: > > $FreeBSD: src/sys/vm/vm_kern.c,v 1.97 2003/04/15 01:16:05 alc Exp $ > $FreeBSD: src/sys/kern/subr_mbuf.c,v 1.47 2003/05/02 03:43:40 silby Exp $ > > I haven't seen this panic previously; a lack of Giant coming out of the > socket code is a bit surprising to me, but I think is unlikely to be a > result of our local MAC tweaks. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Network Associates Laboratories > > > <118>a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout > /usr/X11R6/lib/aout > <118>/etc/rc: INFO: nfsd depends on mountd, which will be forced to start. > <118>Starting mountd. > <118>Starting nfsd. > panic: mutex Giant not owned at ../../../vm/vm_kern.c:315 > P > > Debugger(c04ec67c,c0586b60,c04ebdc3,c8cddb2c,1) at Debugger+0x54 > db> trace > Debugger(c04ec67c,c0586b60,c04ebdc3,c8cddb2c,1) at Debugger+0x54 > panic(c04ebdc3,c04ebefc,c050050a,13b,c04eaf98) at panic+0xab > _mtx_assert(c0584ee0,1,c050050a,13b,4) at _mtx_assert+0xec > kmem_malloc(c0b7f000,2000,2,230,163) at kmem_malloc+0x39 > mb_pop_cont(c0587c20,8,c0b6cac0,2c7,c0b7d700) at mb_pop_cont+0xa0 > mb_alloc(c0587c20,8,e,0,0) at mb_alloc+0x217 > m_get(8,e,5f7,c04eef16,0) at m_get+0x34 > sockargs(c8cddc4c,bfbfd550,60,e,c8cddc68) at sockargs+0x4a > sendit(c192b4c0,c,c8cddcb4,0,806b000) at sendit+0x91 > sendmsg(c192b4c0,c8cddd10,c050602b,3fb,3) at sendmsg+0xc2 > syscall(2f,2f,2f,bfbfd5b0,20) at syscall+0x26e > Xint0x80_syscall() at Xint0x80_syscall+0x1d The change that seems to have done this is: ---- Revision 1.146, Mon May 5 20:33:37 2003 UTC (3 weeks, 1 day ago) by dwmalone Branch: MAIN CVS Tags: HEAD Changes since 1.145: +65 -50 lines Split sendit into two parts. The first part, still called sendit, that does the copyin stuff and then calls the second part kern_sendit to do the hard work. Don't bother holding Giant during the copyin phase. The intent of this is to allow the Linux emulator to impliment send* syscalls without using the stackgap. ---- The problem is that Giant is no longer held in the early parts of sendit which may include the sockargs() call which may end up allocating an mbuf which may end up occasionally calling the VM if the cache is empty. The panic gets triggered in the VM because the call is being made with WAITOK or TRYWAIT. Moving the Giant acquisition from kern_sendit() back to the top of sendit() should fix it, but I'm CCing dwmalone on this to see what he thinks is the best approach. Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030528152151.GA54501>