diff options
author | Eric Dumazet <edumazet@google.com> | 2018-10-18 09:12:19 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2018-10-18 16:51:02 -0700 |
commit | 79861919b8896e14b8e5707242721f2312c57ae4 (patch) | |
tree | e4d0a3a96f8109c5a0aaf295a31bdfffc611622f /kernel/fail_function.c | |
parent | cc18a7543d2f63a2c93fc61cfa7fd8be5464f75e (diff) | |
download | linux-79861919b8896e14b8e5707242721f2312c57ae4.tar.bz2 |
tcp: fix TCP_REPAIR xmit queue setup
Andrey reported the following warning triggered while running CRIU tests:
tcp_clean_rtx_queue()
...
last_ackt = tcp_skb_timestamp_us(skb);
WARN_ON_ONCE(last_ackt == 0);
This is caused by 5f6188a8003d ("tcp: do not change tcp_wstamp_ns
in tcp_mstamp_refresh"), as we end up having skbs in retransmit queue
with a zero skb->skb_mstamp_ns field.
We could fix this bug in different ways, like making sure
tp->tcp_wstamp_ns is not zero at socket creation, but as Neal pointed
out, we also do not want that pacing status of a repaired socket
could push tp->tcp_wstamp_ns far ahead in the future.
So we prefer changing tcp_write_xmit() to not call tcp_update_skb_after_send()
and instead do what is requested by TCP_REPAIR logic.
Fixes: 5f6188a8003d ("tcp: do not change tcp_wstamp_ns in tcp_mstamp_refresh")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andrey Vagin <avagin@openvz.org>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'kernel/fail_function.c')
0 files changed, 0 insertions, 0 deletions