Re: ng_ksocket on CURRENT

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_at_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_at_freebsd.org mailing list
> > T> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > T> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> > 
> > -- 
> > Totus tuus, Glebius.
> > GLEBIUS-RIPN GLEB-RIPE
> > _______________________________________________
> > freebsd-current_at_freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> > 
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>