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