Date: Mon, 5 Jul 2004 12:23:36 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: current@freebsd.org Subject: Re: ng_ksocket on CURRENT Message-ID: <Pine.NEB.3.96L.1040705122205.30459D-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0407050740120.66234-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 5 Jul 2004, Julian Elischer wrote: > It looks like ksocket needs to ensure that it has giant before calling > the network stack. In the debug.mpsafenet=0 scenario, Giant should be held for all of this. The bit of missing information below appears to be how we got onto a call stack without Giant held -- and it looks like that information isn't in the stack trace (?). Normally this would suggest a callout -- I've found a couple that may not be holding Giant properly, but neither looks like it's a match for this trace. Do you know of a way the stack trace below can occur? It looks like the Netgraph netisr holds Giant, and with debug.mpsafenet=0, the inbound network path and system calls should as well. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > > > Robert? > > > On Mon, 5 Jul 2004, Gleb Smirnoff wrote: > > > Actually I can easily reproduce it without WITNESS. > > > > mkpeer xxx: ksocket qqq inet/dgram/udp > > msg xxx:qqq connect inet/127.0.0.1:4444 > > > > Then write something to this node. > > > > > > On Sun, Jul 04, 2004 at 10:30:18PM +0400, Gleb Smirnoff wrote: > > T> I can easily reproduce this panic using today's CURRENT > > T> and ng_ksocket and WITNESS turned on: > > T> > > T> mutex Giant not owned at /usr/src/sys/netinet/udp_usrreq.c:734 > > T> > > T> #0 Debugger (msg=0x12 <Address 0x12 out of bounds>) at atomic.h:263 > > T> #1 0xc0563565 in panic (fmt=0xc0701209 "mutex %s not owned at %s:%d") > > T> at /usr/src/sys/kern/kern_shutdown.c:543 > > T> #2 0xc0559b4c in _mtx_assert (m=0xc0779320, what=-1056882688, > > T> file=0xc070d665 "/usr/src/sys/netinet/udp_usrreq.c", line=734) > > T> at /usr/src/sys/kern/kern_mutex.c:747 > > T> #3 0xc060e47f in udp_output (inp=0xc17af21c, m=0xc172a500, addr=0x0, control=0x0, td=0xc15012c0) > > T> at /usr/src/sys/netinet/udp_usrreq.c:734 > > T> #4 0xc060f067 in udp_send (so=0x12, flags=0, m=0xc172a500, addr=0x12, control=0x12, td=0x12) > > T> at /usr/src/sys/netinet/udp_usrreq.c:1079 > > T> #5 0xc05a31ed in sosend (so=0xc17ae4f0, addr=0x0, uio=0x0, top=0xc172a500, control=0x0, flags=0, > > T> td=0xc15012c0) at /usr/src/sys/kern/uipc_socket.c:788 > > T> #6 0xc05eb595 in ng_ksocket_rcvdata (hook=0xc19e9380, item=0xc17eb7c0) > > T> at /usr/src/sys/netgraph/ng_ksocket.c:917 > > T> #7 0xc05e4fe9 in ng_apply_item (node=0xc19d2800, item=0xc17eb7c0) > > T> at /usr/src/sys/netgraph/ng_base.c:2375 > > T> #8 0xc05e4b95 in ng_snd_item (item=0xc17eb7c0, queue=0) at /usr/src/sys/netgraph/ng_base.c:2264 > > T> #9 0xc1a01b09 in ?? () > > T> #10 0xc17eb7c0 in ?? () > > T> > > T> -- > > T> Totus tuus, Glebius. > > T> GLEBIUS-RIPN GLEB-RIPE > > T> _______________________________________________ > > T> freebsd-current@freebsd.org mailing list > > T> http://lists.freebsd.org/mailman/listinfo/freebsd-current > > T> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > -- > > Totus tuus, Glebius. > > GLEBIUS-RIPN GLEB-RIPE > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040705122205.30459D-100000>