Date: Wed, 09 Nov 2011 16:08:06 +0200 From: Mikolaj Golub <trociny@freebsd.org> To: "Robert N. M. Watson" <rwatson@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r227207 - in head/sys: netinet netinet6 Message-ID: <86vcqtgzi1.fsf@in138.ua3> In-Reply-To: <2494F45C-AEEA-43D6-B373-AACF747A09B6@freebsd.org> (Robert N. M. Watson's message of "Wed, 9 Nov 2011 08:27:16 -0500") References: <201111061047.pA6AlKnc017568@svn.freebsd.org> <86r51lcyn2.fsf@kopusha.home.net> <2494F45C-AEEA-43D6-B373-AACF747A09B6@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 9 Nov 2011 08:27:16 -0500 Robert N. M. Watson wrote: RNMW> On 6 Nov 2011, at 05:51, Mikolaj Golub wrote: >> On Sun, 6 Nov 2011 10:47:20 +0000 (UTC) Mikolaj Golub wrote: >> >> MG> Author: trociny >> MG> Date: Sun Nov 6 10:47:20 2011 >> MG> New Revision: 227207 >> MG> URL: http://svn.freebsd.org/changeset/base/227207 >> >> MG> Log: >> MG> Cache SO_REUSEPORT socket option in inpcb-layer in order to avoid >> MG> inp_socket->so_options dereference when we may not acquire the lock on >> MG> the inpcb. >> MG> >> MG> This fixes the crash due to NULL pointer dereference in >> MG> in_pcbbind_setup() when inp_socket->so_options in a pcb returned by >> MG> in_pcblookup_local() was checked. >> MG> >> MG> Reported by: dave jones <s.dave.jones@gmail.com>, Arnaud Lacombe <lacombar@gmail.com> >> MG> Suggested by: rwatson >> MG> Glanced by: rwatson >> MG> Tested by: dave jones <s.dave.jones@gmail.com> >> >> This commit fixes the panic reported by Dave for 9.0 triggered by >> named. Robert has helped very much suggesting the solution and looking >> at the patches. Unfortunately being saturated on free time he >> couldn't do thorough review of the final version confirming only that >> presumably the approach was correct. >> >> I made an effort to check that there was no regression and SO_REUSEADDR >> worked the same way as it had worked before. But I can't be 100% confident >> that I haven't broken something. Because of this I am going to MFC >> only after the release. >> >> Here is the initial discussion of the issue: >> >> http://lists.freebsd.org/pipermail/freebsd-net/2011-September/029858.html RNMW> Hi Mikolaj: Hi, RNMW> In light of some additional reports of races reminiscent of this one RNMW> (i.e., the UDP crash report on net@ a few days ago), I wonder if we RNMW> should change plans and attempt to get this in the release? I'm sorry I RNMW> haven't had a chance to do a more thorough review, and will try to get RNMW> to that later this week now that my current batch of meetings is RNMW> winding down. I think I saw that report (from sobomax@) and actully it looked for me like not related to this fix. Actually I was not able to find an explanation how it could have happened there :-). Also, although it has not been mentioned in the message according to reffered sources it was stable/8 and it looks like there have been many changes since then in the code. Sure I may have missed something. Nevertheless, I have no any objections to get this fix in the release if people say it is good idea. -- Mikolaj Golub
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86vcqtgzi1.fsf>