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

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
--- syscall (28, FreeBSD ELF32, sendmsg), eip = 0x280d24b3, esp =
0xbfbfd52c, ebp = 0xbfbfd5d8 ---
db> show pcpu
cpuid        = 0
curthread    = 0xc192b4c0: pid 275 "rpcbind"
curpcb       = 0xc8cddda0
fpcurthread  = none
idlethread   = 0xc0b88850: pid 11 "idle"
currentldt   = 0x28
spin locks held:



(kgdb) l *kmem_malloc+0x39
0xc043eea9 is in kmem_malloc (../../../vm/vm_kern.c:317).
312             int pflags;
313
314             if ((flags & M_NOWAIT) == 0)
315                     GIANT_REQUIRED;
316
317             size = round_page(size);
318             addr = vm_map_min(map);
319
320             /*
321              * Locate sufficient space in the map.  This will give us
the final
(kgdb) l *mb_pop_cont+0xa0
0xc0334e10 is in mb_pop_cont (../../../kern/subr_mbuf.c:573).
568             bucket = malloc(sizeof(struct mb_bucket) +
569                 mb_list->ml_objbucks * sizeof(void *), M_MBUF,
MBTOM(how));
570             if (bucket == NULL)
571                     return (NULL);
572
573             p = (caddr_t)kmem_malloc(mb_list->ml_map,
mb_list->ml_objsize * 
574                 mb_list->ml_objbucks, MBTOM(how));
575             if (p == NULL) {
576                     free(bucket, M_MBUF);
577                     if (how == M_TRYWAIT)
(kgdb) l *mb_alloc+0x217
0xc0336057 is in mb_alloc (../../../kern/subr_mbuf.c:712).
707                     } else {
708                             /*
709                              * We'll have to allocate a new page.
710                              */
711                             MB_UNLOCK_CONT(gen_list);
712                             bucket = mb_pop_cont(mb_list, how,
cnt_lst);
713                             if (bucket != NULL) {
714                                     MB_GET_OBJECT(m, bucket, cnt_lst);
715                                     MB_MBTYPES_INC(cnt_lst, type, 1);
716
(kgdb) l *m_get+0x34
0xc0335354 is in m_get (../../../kern/subr_mbuf.c:1186).
1181    struct mbuf *
1182    m_get(int how, short type)
1183    {
1184            struct mbuf *mb;
1185
1186            mb = (struct mbuf *)mb_alloc(&mb_list_mbuf, how, type, 0,
NULL);
1187            if (mb != NULL)
1188                    _mb_setup(mb, type);
1189            return (mb);
1190    }