[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKA=qzZ+L67Z4O7DY0hR_N=5VFSZ2_Dn0to+8WLqnpfgQg+00Q@mail.gmail.com>
Date: Tue, 7 Oct 2014 10:03:29 -0500
From: Josh Hunt <joshhunt00@...il.com>
To: David Miller <davem@...emloft.net>
Cc: per.hurtig@....se, Eric Dumazet <eric.dumazet@...il.com>,
panweiping3@...il.com, nanditad@...gle.com, netdev@...r.kernel.org,
anna.brunstrom@....se, mohammad.rajiullah@....se,
ncardwell@...gle.com, sergei.shtylyov@...entembedded.com
Subject: Re: [PATCH v2 1/1] tcp: fixing TLP's FIN recovery
On Thu, Jun 12, 2014 at 1:06 PM, David Miller <davem@...emloft.net> wrote:
> From: Per Hurtig <per.hurtig@....se>
> Date: Thu, 12 Jun 2014 17:08:32 +0200
>
>> Fix to a problem observed when losing a FIN segment that does not
>> contain data. In such situations, TLP is unable to recover from
>> *any* tail loss and instead adds at least PTO ms to the
>> retransmission process, i.e., RTO = RTO + PTO.
>>
>> Signed-off-by: Per Hurtig <per.hurtig@....se>
>
> Applied, thanks.
Can we queue this up for stable? 2cd0d743b05e87 (tcp: fix
tcp_match_skb_to_sack() for unaligned SACK at end of an skb) is
already in stable and based on the changelog was put in place to fix a
case that this patch introduced:
"This was visible now because the recently simplified TLP logic in
bef1909ee3ed1c ("tcp: fixing TLP's FIN recovery") could find that 0-byte
skb at the end of the write queue, and now that we do not check that
skb's length we could send it as a TLP probe."
However, the patch to fix TLP's FIN recovery is not in -stable.
Thanks
--
Josh
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists