From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net-next] tcp: fix TCP_REPAIR xmit queue setup Date: Thu, 18 Oct 2018 16:51:39 -0700 (PDT) Message-ID: <20181018.165139.1625719491216371041.davem@davemloft.net> References: <20181018161219.127534-1-edumazet@google.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ncardwell@google.com, soheil@google.com, avagin@openvz.org, netdev@vger.kernel.org, eric.dumazet@gmail.com To: edumazet@google.com Return-path: Received: from shards.monkeyblade.net ([23.128.96.9]:42998 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725958AbeJSHzB (ORCPT ); Fri, 19 Oct 2018 03:55:01 -0400 In-Reply-To: <20181018161219.127534-1-edumazet@google.com> Sender: netdev-owner@vger.kernel.org List-ID: From: Eric Dumazet Date: Thu, 18 Oct 2018 09:12:19 -0700 > 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 > Reported-by: Andrey Vagin > Acked-by: Soheil Hassas Yeganeh > Acked-by: Neal Cardwell Applied, thanks Eric.