From owner-svn-src-head@FreeBSD.ORG  Sun Aug 19 11:58:08 2012
Return-Path: <owner-svn-src-head@FreeBSD.ORG>
Delivered-To: svn-src-head@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 7D9C6106566C;
	Sun, 19 Aug 2012 11:58:08 +0000 (UTC)
	(envelope-from rwatson@FreeBSD.org)
Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42])
	by mx1.freebsd.org (Postfix) with ESMTP id 4D91D8FC18;
	Sun, 19 Aug 2012 11:58:08 +0000 (UTC)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41])
	by cyrus.watson.org (Postfix) with ESMTPS id 773F446B0A;
	Sun, 19 Aug 2012 07:58:02 -0400 (EDT)
Date: Sun, 19 Aug 2012 12:58:02 +0100 (BST)
From: Robert Watson <rwatson@FreeBSD.org>
X-X-Sender: robert@fledge.watson.org
To: Randall Stewart <rrs@FreeBSD.org>
In-Reply-To: <201208191154.q7JBs2hc078815@svn.freebsd.org>
Message-ID: <alpine.BSF.2.00.1208191256020.67339@fledge.watson.org>
References: <201208191154.q7JBs2hc078815@svn.freebsd.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org,
	src-committers@freebsd.org
Subject: Re: svn commit: r239395 - head/sys/netinet
X-BeenThere: svn-src-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the src tree for head/-current
	<svn-src-head.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-head>,
	<mailto:svn-src-head-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head>
List-Post: <mailto:svn-src-head@freebsd.org>
List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-head>,
	<mailto:svn-src-head-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Aug 2012 11:58:08 -0000


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