Date: Thu, 10 Dec 2015 12:02:15 -0800 From: Mark Johnston <markj@freebsd.org> To: "Andrey V. Elsukov" <ae@FreeBSD.org> Cc: Jason <j@scre.ws>, freebsd-net@freebsd.org, kevin.bowling@kev009.com, hiren@strugglingcoder.info Subject: Re: Multiple cores/race conditions in IPv6 RA Message-ID: <20151210200215.GB34692@wkstn-mjohnston.west.isilon.com> In-Reply-To: <5667EA3A.8050200@FreeBSD.org> References: <50cff74ea38f155ae616cf49f5ffb5ae@m.nitrology.com> <5667EA3A.8050200@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 09, 2015 at 11:45:46AM +0300, Andrey V. Elsukov wrote: > On 08.12.15 08:32, Jason wrote: > > Hi, > > > > It appears the IPv6 router advertisement code paths were written fairly > > lockless, assuming you would never process multiples concurrently. We > > are seeing multiple page faults in various places processing the > > messages and modifying the routing table. We have multiple L3 devices > > and multiple v6 blocks broadcasting these messages to hardware with dual > > uplinks in the same VLAN, which I believe is making us susceptible to > > this. Though I believe the dual uplink is all that's required for this, > > as it can be seen in configurations with a single v6 block. > > > > We are running stable/10 @ r285800, and it doesn't appear anything > > relevant has changed since then. Our other widely deployed version is > > 8.3-RELEASE, which does not see this issue. Upon bumping a machine from > > 8.3 -> 10 we can see it start to exhibit this behavior. The only change > > I see that might be relevant is r243148, but these cores are relatively > > rare, so testing is tough without a considerable deployment. So > > basically I'm hoping someone with a trained eye can send us in the right > > direction before we go down that road. > > Hi, > > some time ago Mark Johnston has published there the patch related to > this problem: > https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034682.html > > Maybe Mark has something to say about it. I started trying to push this work in with D2254, which fixes some of the global IPv6 addr list locking. It turns out to be pretty tricky to lock both NDP and the global address list properly; the patch in my public directory fixes only some of the issues with NDP and is thus incomplete, which is why I'd been reluctant to push it in. I'll return to D2254 and try and make some further progress on this.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151210200215.GB34692>