Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Aug 2012 12:58:02 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Randall Stewart <rrs@FreeBSD.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r239395 - head/sys/netinet
Message-ID:  <alpine.BSF.2.00.1208191256020.67339@fledge.watson.org>
In-Reply-To: <201208191154.q7JBs2hc078815@svn.freebsd.org>
References:  <201208191154.q7JBs2hc078815@svn.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sun, 19 Aug 2012, Randall Stewart wrote:

>  Though I disagree, I conceed to jhb & Rui. Note
>  that we still have a problem with this whole structure of
>  locks and in_input.c [it does not lock which it should not, but
>  this *can* lead to crashes]. (I have seen it in our SQA
>  testbed.. besides the one with a refcnt issue that I will
>  have SQA work on next week ;-)

I agree with John here -- these are seperate issues, and we need to get each 
part correct in isolation, not just in composition.

Bjoern and I have been plotting a lock reduction exercise in the network stack 
for some time, based on a model Jeff Roberson and the Nokia guys used -- a 
global "config" lock, which would use our rmlock primitive.  This would make 
address list synchronisation sufficiently affordable to use in ip_input(). 
However, it comes with a number of other issues that we need to consider, such 
as potential latency impacts of reconfiguration events, which have to be 
characterised before we commit to it, as well as potential issues with lock 
order.  Recent rmlock improvements (e.g., with respect to WITNESS) make doing 
this work much more plausible.  Hopefully this is something we'll get to in 
September.

Robert



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1208191256020.67339>