diff options
author | Neal Cardwell <ncardwell@google.com> | 2012-02-26 10:06:19 +0000 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2012-03-19 08:57:45 -0700 |
commit | 85526d578a0c7b6723c1a429b39870ce3bfec11c (patch) | |
tree | 7a86e0ecba6e857e67a0f4c84a7901a88d2bde14 /net/unix | |
parent | 2991ddd266470f77442bfb023b2737b6920f8715 (diff) | |
download | kernel_samsung_smdk4412-85526d578a0c7b6723c1a429b39870ce3bfec11c.zip kernel_samsung_smdk4412-85526d578a0c7b6723c1a429b39870ce3bfec11c.tar.gz kernel_samsung_smdk4412-85526d578a0c7b6723c1a429b39870ce3bfec11c.tar.bz2 |
tcp: fix false reordering signal in tcp_shifted_skb
[ Upstream commit 4c90d3b30334833450ccbb02f452d4972a3c3c3f ]
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>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'net/unix')
0 files changed, 0 insertions, 0 deletions