svn commit: r227207 - in head/sys: netinet netinet6

[Mikolaj Golub]

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