Possible bug using ip6_cloutput

[Gerald Lee]

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.
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?
The change we settled on is to bracket the call to ip6_ctloutput
from rip6_ctloutput with splsoftnet. We are open to suggestions...


- bob

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Gerald Lee
The change we settled on is to bracket the call to ip6_ctloutput
from rip6_ctloutput with splsoftnet. We are open to suggestions...

Both analyzis and fix look correct to me.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[JINMEI Tatuya / 神明達哉]

At Fri, 24 Aug 2007 10:29:36 +0200,

Post by Martin Husemann

Post by Gerald Lee
The change we settled on is to bracket the call to ip6_ctloutput
from rip6_ctloutput with splsoftnet. We are open to suggestions...

Both analyzis and fix look correct to me.

Seconded it, but it looks to me that the call from rip_ctloutput() to
ip6_ctloutput() (at least potentially) has the same problem.

JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
***@isl.rdc.toshiba.co.jp

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Gerald Lee
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