[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK6E8=eGaBL9O55xCbtoZuuisvUGF5NRv6qV5bbvQB-JFw6Zjg@mail.gmail.com>
Date: Tue, 10 May 2016 08:01:07 -0700
From: Yuchung Cheng <ycheng@...gle.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: David Miller <davem@...emloft.net>, netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net] tcp: refresh skb timestamp at retransmit time
On Mon, May 9, 2016 at 8:55 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> From: Eric Dumazet <edumazet@...gle.com>
>
> In the very unlikely case __tcp_retransmit_skb() can not use the cloning
> done in tcp_transmit_skb(), we need to refresh skb_mstamp before doing
> the copy and transmit, otherwise TCP TS val will be an exact copy of
> original transmit.
>
> Fixes: 7faee5c0d514 ("tcp: remove TCP_SKB_CB(skb)->when")
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> Cc: Yuchung Cheng <ycheng@...gle.com>
Acked-by: Yuchung Cheng <ycheng@...gle.com>
Nice catch Eric. Recovery algorithm like RACK definitely requires this
patch b/c it relies on skb mstamps.
does the failure usually occur under memory stress?
> ---
> net/ipv4/tcp_output.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 441ae9da3a23..79a03b87a771 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -2640,8 +2640,10 @@ int __tcp_retransmit_skb(struct sock *sk, struct sk_buff *skb)
> */
> if (unlikely((NET_IP_ALIGN && ((unsigned long)skb->data & 3)) ||
> skb_headroom(skb) >= 0xFFFF)) {
> - struct sk_buff *nskb = __pskb_copy(skb, MAX_TCP_HEADER,
> - GFP_ATOMIC);
> + struct sk_buff *nskb;
> +
> + skb_mstamp_get(&skb->skb_mstamp);
> + nskb = __pskb_copy(skb, MAX_TCP_HEADER, GFP_ATOMIC);
> err = nskb ? tcp_transmit_skb(sk, nskb, 0, GFP_ATOMIC) :
> -ENOBUFS;
> } else {
>
>
Powered by blists - more mailing lists