Commit 54695743 authored by Neal Cardwell's avatar Neal Cardwell Committed by Kamal Mostafa

tcp: fix FRTO undo on cumulative ACK of SACKed range

[ Upstream commit 666b8051 ]

On processing cumulative ACKs, the FRTO code was not checking the
SACKed bit, meaning that there could be a spurious FRTO undo on a
cumulative ACK of a previously SACKed skb.

The FRTO code should only consider a cumulative ACK to indicate that
an original/unretransmitted skb is newly ACKed if the skb was not yet
SACKed.

The effect of the spurious FRTO undo would typically be to make the
connection think that all previously-sent packets were in flight when
they really weren't, leading to a stall and an RTO.
Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
Fixes: e33099f9 ("tcp: implement RFC5682 F-RTO")
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
parent ab03d1dc
......@@ -3060,11 +3060,12 @@ static int tcp_clean_rtx_queue(struct sock *sk, int prior_fackets,
if (seq_rtt < 0) {
seq_rtt = ca_seq_rtt;
}
if (!(sacked & TCPCB_SACKED_ACKED))
if (!(sacked & TCPCB_SACKED_ACKED)) {
reord = min(pkts_acked, reord);
if (!after(scb->end_seq, tp->high_seq))
flag |= FLAG_ORIG_SACK_ACKED;
}
}
if (sacked & TCPCB_SACKED_ACKED)
tp->sacked_out -= acked_pcount;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment