netdev - Re: [PATCH] tcp: fixes for DSACK-based undo of cwnd reduction during fast recovery

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 15 Nov 2011 08:13:13 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Neal Cardwell <ncardwell@...gle.com>
cc:	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>, nanditad@...gle.com,
	ycheng@...gle.com, therbert@...gle.com
Subject: Re: [PATCH] tcp: fixes for DSACK-based undo of cwnd reduction during
 fast recovery

On Tue, 15 Nov 2011, Neal Cardwell wrote:
> On Mon, Nov 14, 2011 at 9:05 PM, Ilpo Järvinen
> <ilpo.jarvinen@...sinki.fi> wrote:
> >
> > When you need to say "fixes 1), 2), and 3)", please stop for a moment
> > thinking if the fixes really need to be sent as one fix or 3 fixes (a
> > series PATCH x/3, see netdev for examples). It would make review much
> > simpler if unrelated fixes are not put together even if all of them
> > would be needed to get DSACK working as intented.
> 
> I'm happy to split this patch into a few smaller patches. I was on the
> fence about how fine-grained to make them; I'll make them smaller.

Thanks. In fixes smaller is almost always better. You can then state per 
fix very exactly what is wrong in the code and in what scenario that 
causes problem to materialize for real. Smallness helps the review 
enourmously and all questions raised against can then also remain more 
focused (possibly the rest could be acked/applied immediately, which 
happens quite often actually). You will be surprised yourself too then, 
once you've split each patch becomes very obvious and short (and then I'll 
be more lax about the commit message too as the diff speaks more 
succesfully for itself ;-)).

-- 
 i.