On Tue, 2016-05-10 at 08:01 -0700, Yuchung Cheng wrote:
> On Mon, May 9, 2016 at 8:55 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
> > From: Eric Dumazet <eduma...@google.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 <eduma...@google.com>
> > Cc: Yuchung Cheng <ych...@google.com>
> Acked-by: Yuchung Cheng <ych...@google.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?
For x86, the NET_IP_ALIGN is 0, so the only 'problem' would happen
for devices with big MTU but no SG support.
In the normal case, we allocate small skb->head skbs
(SKB_WITH_OVERHEAD(2048 - MAX_TCP_HEADER) in select_size()
So this bug should not happen for most devices.
RACK will be better, but I was also wondering if PAWS checks on receiver
could drop all subsequent retransmits and we would have a TCP stalled
connection ? That would be a more serious bug.
For arches with NET_IP_ALIGN==2, the bug would be possible if the
receiver is playing games by partially acking the packets we send.
