Date: Sat, 22 Feb 2003 12:18:57 -0300 From: "Daniel C. Sobral" <dcs@newsguy.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: "Daniel C. Sobral" <dcs@tcoip.com.br>, current@FreeBSD.ORG Subject: Re: Witness This Message-ID: <3E5794E1.280FAFA4@newsguy.com> References: <Pine.NEB.3.96L.1030221213431.47317A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > 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. Yeah, I know this one isn't yours. I just decided to take the opportunity and send a single message about all this stuff. > > Now, witness biba: > > Is there any change you have the console output about three or four lines Did you mean "chance" instead of "change"? I'm not sure exactly what do you mean here, but this one followed right on the heels of the previous one on my screen. Not at the same time, though, iirc. At one time I switched to the console, I saw this extra output there. I'll see if it gets reproduced on monday. > 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. MMMmmmmm. Frames #10 and #11? I see mbuflabel=0x0 on frame #10! I can do it. I could send kernel and core to freefall too, if the disk space problem has been solved. MMmmmm. We'll see. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@professional.bsdconspiracy.net Spellng is overated anywy. 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?3E5794E1.280FAFA4>