[net] tcp: fix tcp_fastretrans_alert warning

Message ID 20171107233343.77710-1-ycheng@google.com
State Accepted
Delegated to: David Miller
Headers show
Series
  • [net] tcp: fix tcp_fastretrans_alert warning
Related show

Commit Message

Yuchung Cheng Nov. 7, 2017, 11:33 p.m.
This patch fixes the cause of an WARNING indicatng TCP has pending
retransmission in Open state in tcp_fastretrans_alert().

The root cause is a bad interaction between path mtu probing,
if enabled, and the RACK loss detection. Upong receiving a SACK
above the sequence of the MTU probing packet, RACK could mark the
probe packet lost in tcp_fastretrans_alert(), prior to calling
tcp_simple_retransmit().

tcp_simple_retransmit() only enters Loss state if it newly marks
the probe packet lost. If the probe packet is already identified as
lost by RACK, the sender remains in Open state with some packets
marked lost and retransmitted. Then the next SACK would trigger
the warning. The likely scenario is that the probe packet was
lost due to its size or network congestion. The actual impact of
this warning is small by potentially entering fast recovery an
ACK later.

The simple fix is always entering recovery (Loss) state if some
packet is marked lost during path MTU probing.

Fixes: a0370b3f3f2c ("tcp: enable RACK loss detection to trigger recovery")
Reported-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Reported-by: Roman Gushchin <guro@fb.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
---
 net/ipv4/tcp_input.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Comments

David Miller Nov. 10, 2017, 9:11 a.m. | #1
From: Yuchung Cheng <ycheng@google.com>
Date: Tue,  7 Nov 2017 15:33:43 -0800

> This patch fixes the cause of an WARNING indicatng TCP has pending
> retransmission in Open state in tcp_fastretrans_alert().
> 
> The root cause is a bad interaction between path mtu probing,
> if enabled, and the RACK loss detection. Upong receiving a SACK
> above the sequence of the MTU probing packet, RACK could mark the
> probe packet lost in tcp_fastretrans_alert(), prior to calling
> tcp_simple_retransmit().
> 
> tcp_simple_retransmit() only enters Loss state if it newly marks
> the probe packet lost. If the probe packet is already identified as
> lost by RACK, the sender remains in Open state with some packets
> marked lost and retransmitted. Then the next SACK would trigger
> the warning. The likely scenario is that the probe packet was
> lost due to its size or network congestion. The actual impact of
> this warning is small by potentially entering fast recovery an
> ACK later.
> 
> The simple fix is always entering recovery (Loss) state if some
> packet is marked lost during path MTU probing.
> 
> Fixes: a0370b3f3f2c ("tcp: enable RACK loss detection to trigger recovery")
> Reported-by: Oleksandr Natalenko <oleksandr@natalenko.name>
> Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Reported-by: Roman Gushchin <guro@fb.com>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Reviewed-by: Eric Dumazet <edumazet@google.com>
> Acked-by: Neal Cardwell <ncardwell@google.com>

Applied and queued up for -stable, thank you.

Patch

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 7eec3383702b..91189c58971c 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2614,7 +2614,6 @@  void tcp_simple_retransmit(struct sock *sk)
 	struct tcp_sock *tp = tcp_sk(sk);
 	struct sk_buff *skb;
 	unsigned int mss = tcp_current_mss(sk);
-	u32 prior_lost = tp->lost_out;
 
 	tcp_for_write_queue(skb, sk) {
 		if (skb == tcp_send_head(sk))
@@ -2631,7 +2630,7 @@  void tcp_simple_retransmit(struct sock *sk)
 
 	tcp_clear_retrans_hints_partial(tp);
 
-	if (prior_lost == tp->lost_out)
+	if (!tp->lost_out)
 		return;
 
 	if (tcp_is_reno(tp))