From: <gregkh@linuxfoundation.org>
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: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "tcp: fix tcp_fastretrans_alert warning" has been added to the 4.13-stable tree
Date: Tue, 21 Nov 2017 13:39:21 +0100 [thread overview]
Message-ID: <1511267961206160@kroah.com> (raw)
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 <stable@vger.kernel.org> know about it.
>From foo@baz Tue Nov 21 13:07:20 CET 2017
From: Yuchung Cheng <ycheng@google.com>
Date: Tue, 7 Nov 2017 15:33:43 -0800
Subject: tcp: fix tcp_fastretrans_alert warning
From: Yuchung Cheng <ycheng@google.com>
[ 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 <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>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
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
reply other threads:[~2017-11-21 12:39 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1511267961206160@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alexei.starovoitov@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=guro@fb.com \
--cc=ncardwell@google.com \
--cc=oleksandr@natalenko.name \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=ycheng@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.