summaryrefslogtreecommitdiffstats
path: root/drivers/mfd
diff options
context:
space:
mode:
authorEric Dumazet <edumazet@google.com>2018-10-18 09:12:19 -0700
committerDavid S. Miller <davem@davemloft.net>2018-10-18 16:51:02 -0700
commit79861919b8896e14b8e5707242721f2312c57ae4 (patch)
treee4d0a3a96f8109c5a0aaf295a31bdfffc611622f /drivers/mfd
parentcc18a7543d2f63a2c93fc61cfa7fd8be5464f75e (diff)
downloadlinux-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 'drivers/mfd')
0 files changed, 0 insertions, 0 deletions