tcp: fix false reordering signal in tcp_shifted_skb
authorNeal Cardwell <ncardwell@google.com>
Sun, 26 Feb 2012 10:06:19 +0000 (10:06 +0000)
committerDavid S. Miller <davem@davemloft.net>
Tue, 28 Feb 2012 20:06:46 +0000 (15:06 -0500)
commit4c90d3b30334833450ccbb02f452d4972a3c3c3f
tree36581d7c5fa05c1223e6116f981a5857a02dfb43
parentecb971923614775a118bc05ad16b2bde450cac7d
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>
net/ipv4/tcp_input.c