Subject: Possible bug using ip6_cloutput
To: None <>
From: Gerald Lee <>
List: tech-net
Date: 08/23/2007 10:03:09
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, =
    rip6_ctloutput (op=3D1, so=3D0xf, level=3D5, optname=3D28277504,
    sosetopt (so=3D0x3a3c8018, level=3D41, optname=3D35, =
    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
In response to the above panic, we are adding an splsoftnet in
        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