On one of our systems we had the following panic/stack trace:

    panic (fmt=3D0x2cb758 "")
    trap (frame=3D0x2cb890)
    trapexit ()
    rip6_input (mp=3D0x12, offp=3D0x2cb9bc, proto=3D89)
    ip6_input (m=3D0x3f3d8d00)
    ip6intr ()
    softnet (pendisr=3D16777216)
    xsoftnet (arg=3D0x12)
    intr_dispatch ()
    ext_intr (frame=3D0x12)
    intr_exit ()
    ip6_setmoptions (optname=3D35, im6op=3D0xd06d8f98, m=3D0x3f3b3900)
    ip6_ctloutput (op=3D18, so=3D0x20, level=3D5, optname=3D35, =
mp=3D0x1f)
    rip6_ctloutput (op=3D1, so=3D0xf, level=3D5, optname=3D28277504,
mp=3D0xdaf84e88)
    sosetopt (so=3D0x3a3c8018, level=3D41, optname=3D35, =
m0=3D0x3f3b3900)
    sys_setsockopt (p=3D0x2441faf8, v=3D0xf, retval=3D0x5)
    trap (frame=3D0xdaf84f58)

        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.
In response to the above panic, we are adding an splsoftnet in
ip6_ctloutput.
        I've looked through the current NetBSD code, and the same issue
appears to be there.  Did I miss something? =20
        The change we settled on is to bracket the call to ip6_ctloutput
from rip6_ctloutput with splsoftnet.  We are open to suggestions...


- bob