Date: Fri, 21 Feb 2003 21:40:31 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: "Daniel C. Sobral" <dcs@tcoip.com.br> Cc: current@freebsd.org Subject: Re: Witness This Message-ID: <Pine.NEB.3.96L.1030221213431.47317A-100000@fledge.watson.org> In-Reply-To: <3E5677AF.9060005@tcoip.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Feb 2003, Daniel C. Sobral wrote:
> backtrace(c032e7d9,c25af500,c25a98d4,c046236e,c04623ec) at
> backtrace+0x17
>
> witness_lock(c25af500,8,c04623ec,1b8,c) at witness_lock+0x660
> _mtx_lock_flags(c25af500,0,c04623ec,1b8,80000095) at
> _mtx_lock_flags+0xb1 chn_intr(c25a9880,c,10000,208,c25af7c0) at
> chn_intr+0x2f cmi_intr(c25a9800,0,c0329618,217,c25ae9ec) at
> cmi_intr+0xa6 ithread_loop(c25a9000,cd2ced48,c032948d,366,55ff44fd) at
> ithread_loop+0x182 fork_exit(c01cd420,c25a9000,cd2ced48) at
> fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1,
> eip = 0, esp = 0xcd2ced7c, ebp = 0 ---
This one is probably not my fault, but may well be of interest to
Jeffrey Hsu.
> Now, witness biba:
Is there any change you have the console output about three or four lines
above this? It identifies the locks in the lock order reversal. It
sounds like a lock might be held in getnewvnode() across
mac_destroy_vnode_label, which in the original design it wasn't intended
to be, and that might result in the reversal. I'll have to take a closer
look at that.
> Finally, trace this:
...
> #8 0xc01eb0bb in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:528
> td = (struct thread *) 0xc0ecba50
> bootopt = 256
> newpanic = 1
> buf = "mac_mls_single_in_range: a not single", '\0' <repeats 218 times>
> #9 0xc0277274 in mac_mls_single_in_range (single=0x0, range=0xc2605e80)
> at /usr/src/sys/security/mac_mls/mac_mls.c:225
> No locals.
> #10 0xc0278cb6 in mac_mls_check_ifnet_transmit (ifnet=0xc25ebc00,
> ifnetlabel=0x0, m=0xc0eda000, mbuflabel=0x0)
> at /usr/src/sys/security/mac_mls/mac_mls.c:1462
> p = (struct mac_mls *) 0x0
> i = (struct mac_mls *) 0x0
> #11 0xc01dad7a in mac_check_ifnet_transmit (ifnet=0xc25ebc00,
> mbuf=0xc0eda000)
> at /usr/src/sys/kern/kern_mac.c:2269
> mpc = (struct mac_policy_conf *) 0xc2605e80
> error = 0
I'm a bit puzzled by this; it could be this relates to recent changes
regarding when socket state is discarded. Especially odd are the
ifnetlabel and mbuflabel arguments being NULL, as well as the two mac_mls
pointers. Really they should be non-NULL, or you would have panicked
earlier, so perhaps there's stack corruption. If you still have this
dump, you might consider walking back up the stack to these two frames,
and printing the contents of *ifnetlabel and *mbuflabel, as well as
the two struct mac_mls values in mac_mls_check_ifnet_transmit.
BTW, the attached patch might also be useful, as it's possible there's now
a NULL pointer dereference here now. I don't think the trace you have
above will be fixed by this change, but you never know. :-)
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
Index: tcp_subr.c
===================================================================
RCS file: /data/fbsd-cvs/ncvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.155
diff -u -r1.155 tcp_subr.c
--- tcp_subr.c 21 Feb 2003 23:17:12 -0000 1.155
+++ tcp_subr.c 22 Feb 2003 02:34:07 -0000
@@ -484,7 +484,7 @@
m->m_pkthdr.len = tlen;
m->m_pkthdr.rcvif = (struct ifnet *) 0;
#ifdef MAC
- if (tp != NULL) {
+ if (tp != NULL && tp->t_inpcp != NULL) {
/*
* Packet is associated with a socket, so allow the
* label of the response to reflect the socket label.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030221213431.47317A-100000>