From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:47538 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752018AbdKUMj1 (ORCPT ); Tue, 21 Nov 2017 07:39:27 -0500 Subject: Patch "tcp: fix tcp_fastretrans_alert warning" has been added to the 4.13-stable tree To: ycheng@google.com, alexei.starovoitov@gmail.com, davem@davemloft.net, edumazet@google.com, gregkh@linuxfoundation.org, guro@fb.com, ncardwell@google.com, oleksandr@natalenko.name Cc: , From: Date: Tue, 21 Nov 2017 13:39:21 +0100 Message-ID: <1511267961206160@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled tcp: fix tcp_fastretrans_alert warning to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: tcp-fix-tcp_fastretrans_alert-warning.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Yuchung Cheng Date: Tue, 7 Nov 2017 15:33:43 -0800 Subject: tcp: fix tcp_fastretrans_alert warning From: Yuchung Cheng [ Upstream commit 0eb96bf754d7fa6635aa0b0f6650c74b8a6b1cc9 ] 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 Reported-by: Alexei Starovoitov Reported-by: Roman Gushchin Signed-off-by: Yuchung Cheng Reviewed-by: Eric Dumazet Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/ipv4/tcp_input.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -2613,7 +2613,6 @@ void tcp_simple_retransmit(struct sock * 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)) @@ -2630,7 +2629,7 @@ void tcp_simple_retransmit(struct sock * tcp_clear_retrans_hints_partial(tp); - if (prior_lost == tp->lost_out) + if (!tp->lost_out) return; if (tcp_is_reno(tp)) Patches currently in stable-queue which might be from ycheng@google.com are queue-4.13/tcp-fix-tcp_fastretrans_alert-warning.patch