Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Mar 2003 17:05:14 -0300
From:      "Daniel C. Sobral" <dcs@tcoip.com.br>
To:        Robert Watson <rwatson@FreeBSD.ORG>
Cc:        CURRENT <freebsd-current@FreeBSD.ORG>
Subject:   Re: IP stack problem -- possibly mac-related
Message-ID:  <3E8207FA.7090704@tcoip.com.br>
In-Reply-To: <Pine.NEB.3.96L.1030324130519.31378I-100000@fledge.watson.org>
References:  <Pine.NEB.3.96L.1030324130519.31378I-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------000602040508040609040901
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

X marks the spot.

Robert Watson wrote:
> On Mon, 24 Mar 2003, Daniel C. Sobral wrote:
> 
> 
>>The messages below are from today's kernel + mac_mls and mac_biba
>>kld-loaded from loader(8). None of the warning appear if these modules
>>are not loaded (I haven't tried not loading one and then the other, but
>>I can do it on request) 
> 
> ...
> 
>>malloc() of "128" with the following non-sleepablelocks held:
>>exclusive sleep mutex inp r = 0 (0xc280a6ec) locked @ 
>>/usr/src/sys/netinet/udp_usrreq.c:1034
>>exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ 
>>/usr/src/sys/netinet/udp_usrreq.c:1027
> 
> 
> Hmm.  I think there's a witness flag to generate stack traces when giving
> out these sorts of warnings -- debug.witness_trace I think.  Can you try
> turning that on in loader.conf and see if we get some additional
> information?  The only MAC call in udp_output() is
> mac_create_mbuf_from_socket(), which isn't supposed to result in memory
> allocation.  That should only happen when the mbuf itself is allocated.  A
> stack trace might narrow down the source of the problem.
> 
> Thanks,
> 
> Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
> robert@fledge.watson.org      Network Associates Laboratories


-- 
Daniel C. Sobral                   (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: Daniel.Capo@tco.net.br
         Daniel.Sobral@tcoip.com.br
         dcs@tcoip.com.br

Outros:
	dcs@newsguy.com
	dcs@freebsd.org
	capo@notorious.bsdconspiracy.net

"I didn't know it was impossible when I did it."

--------------000602040508040609040901
Content-Type: text/plain;
 name="x"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="x"

malloc() of "128" with the following non-sleepablelocks held:
exclusive sleep mutex radix node head r = 1 (0xc262507c) locked @ /usr/src/sys/n
et/route.c:549
Debugger("witness_warn")
Stopped at      Debugger+0x54:  xchgl   %ebx,in_Debugger.0
db> trace
Debugger(c031017c,cdccd920,1,c01e1a5d,c0472780) at Debugger+0x54
witness_warn(5,0,c033579a,c0324ee1,c03290a8) at witness_warn+0x1a0
uma_zalloc_arg(c083cd80,0,104,246,c0353260) at uma_zalloc_arg+0x53
malloc(70,c0472780,104,cdccd98c,c046ed20) at malloc+0xd4
mls_alloc(4,c0472a60,c0ee3d30,cdccd9b0,c01d1776) at mls_alloc+0x26
mac_mls_init_label_waitcheck(c0ee3d30,4,c0324cf0,2d0,c0ee3d00) at mac_mls_init_l
abel_waitcheck+0x20
mac_init_mbuf(c0ee3d00,4,1,0,0) at mac_init_mbuf+0xb6
m_gethdr(4,1,cdccd9f0,cdccda4c,5c) at m_gethdr+0x7f
rt_msg1(1,cdccda50,20005,0,c26c2500) at rt_msg1+0x79
rt_missmsg(1,cdccda50,20405,0,0) at rt_missmsg+0x2a
rtalloc1(c25fc7ec,1,10000,cdccdacc,c01dfd54) at rtalloc1+0x165
rt_setgate(c26c2400,c25fc7dc,c25fc7ec,225,3) at rt_setgate+0x1d8
rtrequest1(1,cdccdb40,cdccdb38,c25fc800,0) at rtrequest1+0x2c9
route_output(c0ee3e00,c280d700,80,c0ee3e00,1f80) at route_output+0x246
raw_usend(c280d700,0,c0ee3e00,0,0) at raw_usend+0x7d
rts_send(c280d700,0,c0ee3e00,0,0) at rts_send+0x35
sosend(c280d700,0,cdccdc7c,c0ee3e00,0) at sosend+0x4bd
soo_write(c26dab04,cdccdc7c,c0eca100,0,c256c3c0) at soo_write+0x97
dofilewrite(c256c3c0,c26dab04,3,80b7340,80) at dofilewrite+0xe8
write(c256c3c0,cdccdd10,c0339162,404,3) at write+0x69
syscall(2f,2f,2f,80b739c,80) at syscall+0x26e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4, FreeBSD ELF32, write), eip = 0x804b90f, esp = 0xbfbffd0c, ebp =
0xbfbffd28 ---
db> c
malloc() of "128" with the following non-sleepablelocks held:
exclusive sleep mutex radix node head r = 1 (0xc262507c) locked @ /usr/src/sys/n
et/route.c:549
Debugger("witness_warn")
Stopped at      Debugger+0x54:  xchgl   %ebx,in_Debugger.0
db> trace
Debugger(c031017c,cdccd920,1,c0353260,c046a2e0) at Debugger+0x54
witness_warn(5,0,c033579a,c0324ee1,167) at witness_warn+0x1a0
uma_zalloc_arg(c083cd80,0,104,e0,c25fc700) at uma_zalloc_arg+0x53
malloc(70,c046a2e0,104,cdccd98c,c0466fa0) at malloc+0xd4
biba_alloc(4,c046a5c0,c0ee3d30,cdccd9b0,c01d1776) at biba_alloc+0x26
mac_biba_init_label_waitcheck(c0ee3d30,4,c0324cf0,2d0,c0ee3d00) at mac_biba_init
_label_waitcheck+0x20
mac_init_mbuf(c0ee3d00,4,1,0,0) at mac_init_mbuf+0xb6
m_gethdr(4,1,cdccd9f0,cdccda4c,5c) at m_gethdr+0x7f
rt_msg1(1,cdccda50,20005,0,c26c2500) at rt_msg1+0x79
rt_missmsg(1,cdccda50,20405,0,0) at rt_missmsg+0x2a
rtalloc1(c25fc7ec,1,10000,cdccdacc,c01dfd54) at rtalloc1+0x165
rt_setgate(c26c2400,c25fc7dc,c25fc7ec,225,3) at rt_setgate+0x1d8
rtrequest1(1,cdccdb40,cdccdb38,c25fc800,0) at rtrequest1+0x2c9
route_output(c0ee3e00,c280d700,80,c0ee3e00,1f80) at route_output+0x246
raw_usend(c280d700,0,c0ee3e00,0,0) at raw_usend+0x7d
rts_send(c280d700,0,c0ee3e00,0,0) at rts_send+0x35
sosend(c280d700,0,cdccdc7c,c0ee3e00,0) at sosend+0x4bd
soo_write(c26dab04,cdccdc7c,c0eca100,0,c256c3c0) at soo_write+0x97
dofilewrite(c256c3c0,c26dab04,3,80b7340,80) at dofilewrite+0xe8
write(c256c3c0,cdccdd10,c0339162,404,3) at write+0x69
syscall(2f,2f,2f,80b739c,80) at syscall+0x26e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4, FreeBSD ELF32, write), eip = 0x804b90f, esp = 0xbfbffd0c, ebp =
0xbfbffd28 ---
db> c
add net default: gateway 10.0.7.21


--------------000602040508040609040901--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E8207FA.7090704>