Date: Wed, 28 Nov 2012 08:31:01 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Andre Oppermann <andre@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Peter Wemm <peter@wemm.org> Subject: Re: svn commit: r243627 - head/sys/kern Message-ID: <alpine.BSF.2.00.1211280827590.37292@fledge.watson.org> In-Reply-To: <50B5C4F1.1020002@freebsd.org> References: <201211272004.qARK4qS8047209@svn.freebsd.org> <CAGE5yCpxOdsjefe6quR_gjs82pk9a2e_H_WUNUWhUGA3WZPJaw@mail.gmail.com> <50B54180.5020608@freebsd.org> <alpine.BSF.2.00.1211272246560.37292@fledge.watson.org> <50B54492.5040100@freebsd.org> <956CE44A-BA0F-4FE4-AA38-F4B90C85ECBA@FreeBSD.org> <50B54CE0.6080008@freebsd.org> <2A12C740-1D72-4D30-B663-47A37AAC2FF3@FreeBSD.org> <50B5C4F1.1020002@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Nov 2012, Andre Oppermann wrote: > Yes, and I didn't really expect you to answer (at least quickly) during your > FreeBSD hiatus. So it was seeking review by chance. > > Alas I found and fixed the bug myself within 2.5hrs. While not optimal, a > sign of poor prior testing and too much trust into the submitter of the > patch it wasn't an earth shattering event. Doesn't distract from the fact > that it was mea culpa in any case though. The rapid fix was, of course, extremely appreciated :-). > For prior review of kern_socket* and netinet/tcp_* related changes it has > been on and off by various committers over the past year. If we do have a > policy of prior review required then it should be made official and codified > in MAINTAINERS and universally applied to all. I tend to be of the view that 'maintainers' is a bad idea, and that we should just make a regular practice of seeking review for this sort of thing, especially as our community grows (and, let us be honest, complexity also grows -- your observations about decades of accumulated complexity in the TCP stack are not amiss). I'll try to take a look at this change in detail over the weekend -- listen/accept locking is a bit of a sore point; in the original design, I didn't have a separate accept lock, but ended up being forced to introduce it to solve races along these lines. In the past we've also relied on the pcbinfo lock in the protocol providing significant synchronisation during new connection events, and as we reduce the influence of that lock, finding more structured solutions is necessary. Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1211280827590.37292>