This is a note to let you know that I've just added the patch titled

    tcp: fixing TLP's FIN recovery

to the 3.14-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-fixing-tlp-s-fin-recovery.patch
and it can be found in the queue-3.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.


>From foo@baz Sun Oct 12 16:38:53 CEST 2014
From: Per Hurtig <[email protected]>
Date: Thu, 12 Jun 2014 17:08:32 +0200
Subject: tcp: fixing TLP's FIN recovery

From: Per Hurtig <[email protected]>

[ Upstream commit bef1909ee3ed1ca39231b260a8d3b4544ecd0c8f ]

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 <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Acked-by: Nandita Dukkipati <[email protected]>
Acked-by: Neal Cardwell <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
 net/ipv4/tcp_output.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2069,9 +2069,7 @@ void tcp_send_loss_probe(struct sock *sk
        if (WARN_ON(!skb || !tcp_skb_pcount(skb)))
                goto rearm_timer;
 
-       /* Probe with zero data doesn't trigger fast recovery. */
-       if (skb->len > 0)
-               err = __tcp_retransmit_skb(sk, skb);
+       err = __tcp_retransmit_skb(sk, skb);
 
        /* Record snd_nxt for loss detection. */
        if (likely(!err))


Patches currently in stable-queue which might be from [email protected] are

queue-3.14/tcp-fixing-tlp-s-fin-recovery.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to