diff options
author | Neal Cardwell <ncardwell@google.com> | 2012-02-26 10:06:19 (GMT) |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2012-02-28 20:06:46 (GMT) |
commit | 4c90d3b30334833450ccbb02f452d4972a3c3c3f (patch) | |
tree | 36581d7c5fa05c1223e6116f981a5857a02dfb43 /net/ipv4/Makefile | |
parent | ecb971923614775a118bc05ad16b2bde450cac7d (diff) | |
download | linux-4c90d3b30334833450ccbb02f452d4972a3c3c3f.tar.xz |
tcp: fix false reordering signal in tcp_shifted_skb
When tcp_shifted_skb() shifts bytes from the skb that is currently
pointed to by 'highest_sack' then the increment of
TCP_SKB_CB(skb)->seq implicitly advances tcp_highest_sack_seq(). This
implicit advancement, combined with the recent fix to pass the correct
SACKed range into tcp_sacktag_one(), caused tcp_sacktag_one() to think
that the newly SACKed range was before the tcp_highest_sack_seq(),
leading to a call to tcp_update_reordering() with a degree of
reordering matching the size of the newly SACKed range (typically just
1 packet, which is a NOP, but potentially larger).
This commit fixes this by simply calling tcp_sacktag_one() before the
TCP_SKB_CB(skb)->seq advancement that can advance our notion of the
highest SACKed sequence.
Correspondingly, we can simplify the code a little now that
tcp_shifted_skb() should update the lost_cnt_hint in all cases where
skb == tp->lost_skb_hint.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/ipv4/Makefile')
0 files changed, 0 insertions, 0 deletions