svn commit: r227207 - in head/sys: netinet netinet6
Mikolaj Golub
trociny at freebsd.org
Wed Nov 9 14:08:15 UTC 2011
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 at gmail.com>, Arnaud Lacombe <lacombar at gmail.com>
>> MG> Suggested by: rwatson
>> MG> Glanced by: rwatson
>> MG> Tested by: dave jones <s.dave.jones at 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
More information about the svn-src-head
mailing list