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>