On Tue, Oct 11, 2011 at 12:27:17PM +0200, David Täht wrote:
> On my list already would be "an analysis of the effects of broken sack
> processing on linux 2.4.24-3.1", of which I *think* I've captured
> multiple examples of in the raw traces I've been collecting for
> months... (so if anyone is interested in the raw data, I can provide)
Do you have any more information? The only thing I could find online was that
there were SACK issues that were supposed to be fixed by 2.6.16; nothing
about a fix in 3.1 or post-3.1.
This was a typo on my part - 2.6.24-3.1, not 2.4
The specific commit that concerned me was this one. I had seen
multiple cases of odd behavior (basically tcp sacking like crazy
until the cwr collapses or a tcp reset) that I *think* this fix
explains.
commit f779b2d60ab95c17f1e025778ed0df3ec2f05d75
Author: Zheng Yan <zheng.z.yan@intel.com>
Date: Sun Sep 18 22:37:34 2011 -0400
tcp: fix validation of D-SACK
D-SACK is allowed to reside below snd_una. But the corresponding
check
in tcp_is_sackblock_valid() is the exact opposite. It looks like
a typo.
Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
--
Dave Täht