On Thu, Aug 23, 2007 at 10:03:09AM -0700, Gerald Lee wrote:
> On one of our systems we had the following panic/stack trace:
> 
>     panic (fmt=0x2cb758 "")
>     trap (frame=0x2cb890)
>     trapexit ()
>     rip6_input (mp=0x12, offp=0x2cb9bc, proto=89)
>     ip6_input (m=0x3f3d8d00)
>     ip6intr ()
>     softnet (pendisr=16777216)
>     xsoftnet (arg=0x12)
>     intr_dispatch ()
>     ext_intr (frame=0x12)
>     intr_exit ()
>     ip6_setmoptions (optname=35, im6op=0xd06d8f98, m=0x3f3b3900)
>     ip6_ctloutput (op=18, so=0x20, level=5, optname=35, mp=0x1f)
>     rip6_ctloutput (op=1, so=0xf, level=5, optname=28277504,
> mp=0xdaf84e88)
>     sosetopt (so=0x3a3c8018, level=41, optname=35, m0=0x3f3b3900)
>     sys_setsockopt (p=0x2441faf8, v=0xf, retval=0x5)
>     trap (frame=0xdaf84f58)
> 
>         ip6_ctloutput is called from two places, tcp_usrreq and from
> (seen above) rip6_ctloutput.  In tcp_usrreq the call is bracketed by
> splsoftnet, but no such concurrency control is in place in
> rip6_ctloutput.

It also seems problematic to me that udp6_usrreq() calls udp6_output()
without IPL_SOFTNET protection.  What do you think?

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933 ext 24