aboutsummaryrefslogtreecommitdiffstats
path: root/net/unix
diff options
context:
space:
mode:
authorNeal Cardwell <ncardwell@google.com>2012-02-26 10:06:19 +0000
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2012-03-19 08:57:45 -0700
commit85526d578a0c7b6723c1a429b39870ce3bfec11c (patch)
tree7a86e0ecba6e857e67a0f4c84a7901a88d2bde14 /net/unix
parent2991ddd266470f77442bfb023b2737b6920f8715 (diff)
downloadkernel_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