Re: mb alloc and: panic: mutex Giant not owned at ../../../vm/vm_kern.c:315

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_at_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_at_unixdaemons.com
bmilekic_at_FreeBSD.org