From patchwork Mon Aug 7 13:45:45 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Menglong Dong X-Patchwork-Id: 13344272 X-Patchwork-Delegate: kuba@kernel.org Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 48A7D107BA for ; Mon, 7 Aug 2023 13:47:17 +0000 (UTC) Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C4A3E53; Mon, 7 Aug 2023 06:47:15 -0700 (PDT) Received: by mail-pl1-x641.google.com with SMTP id d9443c01a7336-1bb84194bf3so29411185ad.3; Mon, 07 Aug 2023 06:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691416035; x=1692020835; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=VvRHs0oQl+CF4CqoniuHI9S6BlLWdP4X6ChmtvgMCww=; b=svAlTn21dkZIGdxfF3T2QxXCXmc4WyXl8RIkqygcuSnC+LWDaDtj5+lXcwzYrEMEVA TjcfsQtcUoyoH0Yx83G1N1pPqw3sEW6J0gqgra+qTz+9Fs/eDNxJziSJrpU8ilu4Qt6c zQqL0qsxmQrSViZcqrm2cioAYMopw9fJV5SFavpRrPgDVrhhYKDP1HlN2+o1Q0yUChzQ QE9DZwTzbX6rbKwhyGePQc2vFOBlXmSaTg03zZbHGpeKbU4Qr2ThpQWXvS19hgXIhKDR mAEg+7cGyHMO+Wtq5OcgWM5x2prFAUEy4jasQvNr22gUZZ67B9ksOHbusDEfwWzKW2aW cRoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691416035; x=1692020835; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VvRHs0oQl+CF4CqoniuHI9S6BlLWdP4X6ChmtvgMCww=; b=VyDwwfJsd2S5eYApTF3h5ZhOFZX8rVHWsKJvv2NdJJliy0B7CAjX3gz7WzEdegAL2u rfxM7U111RNZmW3au5jhRSBk18Wwzjz0nSrogE+61lc2FCiFYKdLVj4Xi0qmZWMzUE0l vRZzQq60v82hartPyZMxv4MWoDRn4xEoNfQc8VjRGNFypZN1bYJzLisSgyMGOrTqs84j 37WwfwrQr9b9nTHWk8UFNN4eDXC49EUix1r2ZcXZb3DV/uabnM3q/kTL16Nb3N2AppSO w0JTlxmO5wWpeWSb10gfQeXegYRs7rjJhdTOt9GEGoclZmPosvmDDHR5QW1X8yARD8Er RMUw== X-Gm-Message-State: AOJu0YxwKh5vEx4IU3r3S4QRFfaFgREYLfeto2UHaeh8RMGJUcjumR3t /B3p7YL1OI2dRx8cjZn1lKg= X-Google-Smtp-Source: AGHT+IGo9ZA9f/X75Ozpaoe1bJghhVKHuLA3Fjfd7lrguHqy0CTs1/AtSC27A6MrgzKlinLfp0Iu2w== X-Received: by 2002:a17:902:b20e:b0:1bb:6eeb:7a08 with SMTP id t14-20020a170902b20e00b001bb6eeb7a08mr8812654plr.10.1691416034543; Mon, 07 Aug 2023 06:47:14 -0700 (PDT) Received: from localhost.localdomain ([203.205.141.23]) by smtp.gmail.com with ESMTPSA id h2-20020a170902704200b001b54a88e4a6sm6912097plt.51.2023.08.07.06.47.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Aug 2023 06:47:14 -0700 (PDT) From: menglong8.dong@gmail.com X-Google-Original-From: imagedong@tencent.com To: edumazet@google.com, ncardwell@google.com Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, dsahern@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Menglong Dong Subject: [PATCH net-next v2 1/3] net: tcp: send zero-window ACK when no memory Date: Mon, 7 Aug 2023 21:45:45 +0800 Message-Id: <20230807134547.2782227-2-imagedong@tencent.com> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20230807134547.2782227-1-imagedong@tencent.com> References: <20230807134547.2782227-1-imagedong@tencent.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net X-Patchwork-Delegate: kuba@kernel.org From: Menglong Dong For now, skb will be dropped when no memory, which makes client keep retrans util timeout and it's not friendly to the users. In this patch, we reply an ACK with zero-window in this case to update the snd_wnd of the sender to 0. Therefore, the sender won't timeout the connection and will probe the zero-window with the retransmits. Signed-off-by: Menglong Dong --- v2: - send 0 rwin ACK for the receive queue empty case when necessary - send the ACK immediately by using the ICSK_ACK_NOW flag --- include/net/inet_connection_sock.h | 3 ++- net/ipv4/tcp_input.c | 14 +++++++++++--- net/ipv4/tcp_output.c | 14 +++++++++++--- 3 files changed, 24 insertions(+), 7 deletions(-) diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h index c2b15f7e5516..be3c858a2ebb 100644 --- a/include/net/inet_connection_sock.h +++ b/include/net/inet_connection_sock.h @@ -164,7 +164,8 @@ enum inet_csk_ack_state_t { ICSK_ACK_TIMER = 2, ICSK_ACK_PUSHED = 4, ICSK_ACK_PUSHED2 = 8, - ICSK_ACK_NOW = 16 /* Send the next ACK immediately (once) */ + ICSK_ACK_NOW = 16, /* Send the next ACK immediately (once) */ + ICSK_ACK_NOMEM = 32, }; void inet_csk_init_xmit_timers(struct sock *sk, diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 8e96ebe373d7..aae485d0a3b6 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -5059,12 +5059,20 @@ static void tcp_data_queue(struct sock *sk, struct sk_buff *skb) /* Ok. In sequence. In window. */ queue_and_out: - if (skb_queue_len(&sk->sk_receive_queue) == 0) - sk_forced_mem_schedule(sk, skb->truesize); - else if (tcp_try_rmem_schedule(sk, skb, skb->truesize)) { + if (skb_queue_len(&sk->sk_receive_queue) == 0) { + if (tcp_try_rmem_schedule(sk, skb, skb->truesize)) { + sk_forced_mem_schedule(sk, skb->truesize); + inet_csk(sk)->icsk_ack.pending |= + (ICSK_ACK_NOMEM | ICSK_ACK_NOW); + inet_csk_schedule_ack(sk); + } + } else if (tcp_try_rmem_schedule(sk, skb, skb->truesize)) { reason = SKB_DROP_REASON_PROTO_MEM; NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPRCVQDROP); sk->sk_data_ready(sk); + inet_csk(sk)->icsk_ack.pending |= + (ICSK_ACK_NOMEM | ICSK_ACK_NOW); + inet_csk_schedule_ack(sk); goto drop; } diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index c5412ee77fc8..769a558159ee 100644 --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -257,11 +257,19 @@ EXPORT_SYMBOL(tcp_select_initial_window); static u16 tcp_select_window(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); - u32 old_win = tp->rcv_wnd; - u32 cur_win = tcp_receive_window(tp); - u32 new_win = __tcp_select_window(sk); struct net *net = sock_net(sk); + u32 old_win = tp->rcv_wnd; + u32 cur_win, new_win; + + /* Make the window 0 if we failed to queue the data because we + * are out of memory. The window is temporary, so we don't store + * it on the socket. + */ + if (unlikely(inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM)) + return 0; + cur_win = tcp_receive_window(tp); + new_win = __tcp_select_window(sk); if (new_win < cur_win) { /* Danger Will Robinson! * Don't update rcv_wup/rcv_wnd here or else From patchwork Mon Aug 7 13:45:46 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Menglong Dong X-Patchwork-Id: 13344273 X-Patchwork-Delegate: kuba@kernel.org Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AD35A10952 for ; Mon, 7 Aug 2023 13:47:19 +0000 (UTC) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F60A10D5; Mon, 7 Aug 2023 06:47:18 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id d9443c01a7336-1bbd03cb7c1so28376995ad.3; Mon, 07 Aug 2023 06:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691416037; x=1692020837; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ujZiVs9WYzU9nGaUspRh3pJHwz3VwVmUv7LZdW5BRhE=; b=QiU/70y8hV0yRGawTxx8X4WMJJJ6A8PQ/M+j1eP1xpUj2WI6TkxhC9NoGqo2Yc1ly1 MyFyd/zy5EHwdxAhxKYiM/rZ43ZctBXvSijSH4Y264vd8QyoMisSzrBBuOxug/okDsG6 MVG8gX1VYvds4lLcWKZZsQvxHXuI0RijwimGg0uAXi8Cb4OWIgf/s/weRONZ0F8hL/UZ Y/9xbPyR9418eLrcia8NaCFYu2VwzpKkKWxBCLHWahB4dyQupl2pSl3bQLipvXu7Wksb 8P9JEQMf4N2P8/CnIzaAwY7GGMYhER/I7ie+8WtTQ9FBtClII7che7vCP/T9ttpF3eyz zMqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691416037; x=1692020837; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ujZiVs9WYzU9nGaUspRh3pJHwz3VwVmUv7LZdW5BRhE=; b=OvRiq/YXP7H81Svv9Om+qQXUpOm8fZ+/5DMRRQAkor4kqRkBjfNMU/MXIryK1R1+bf LuQ8JUT+pRhbn2JpOSYTltYEe80P4YywOVGdUnSDfs5/t+CKJ5y5r/LEeQK/MZx/P7nH h8PBUNAmUQgCticlexzKKJctY/pSeRfWMiTt2YKW4ZTJiaX0wDLWGG5wmn3wPZc2JUap Rj3dz8MV9s4q58IfIqvdd3fGqY9uMiw66Vb4QoIj2Li2eQpIgCiEwqYn3WuTvgzO8zkO jV1LucpJzDqUoGjK4GxY+E1Hmm7UHrPPaH8cxtRN5JMryxj/+hm/gT10FuIjH+oyhir0 OfLA== X-Gm-Message-State: AOJu0Yy81832ttY8/itMj2JfQqs23L6T1ZOxL7cZgB2kPVQVv602rJqn nAG5Y1fgzLI8gQCAvm9MqeA= X-Google-Smtp-Source: AGHT+IHqAZ/HoDVBS19gynk+DiCMvNQ708LWevboxkgOEgFd7C8CKbB6TI9I0CALezHxRYM/YYDfJg== X-Received: by 2002:a17:902:dad2:b0:1b6:6c32:59a8 with SMTP id q18-20020a170902dad200b001b66c3259a8mr7472543plx.36.1691416037440; Mon, 07 Aug 2023 06:47:17 -0700 (PDT) Received: from localhost.localdomain ([203.205.141.23]) by smtp.gmail.com with ESMTPSA id h2-20020a170902704200b001b54a88e4a6sm6912097plt.51.2023.08.07.06.47.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Aug 2023 06:47:16 -0700 (PDT) From: menglong8.dong@gmail.com X-Google-Original-From: imagedong@tencent.com To: edumazet@google.com, ncardwell@google.com Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, dsahern@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Menglong Dong Subject: [PATCH net-next v2 2/3] net: tcp: allow zero-window ACK update the window Date: Mon, 7 Aug 2023 21:45:46 +0800 Message-Id: <20230807134547.2782227-3-imagedong@tencent.com> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20230807134547.2782227-1-imagedong@tencent.com> References: <20230807134547.2782227-1-imagedong@tencent.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net X-Patchwork-Delegate: kuba@kernel.org From: Menglong Dong Fow now, an ACK can update the window in following case, according to the tcp_may_update_window(): 1. the ACK acknowledged new data 2. the ACK has new data 3. the ACK expand the window and the seq of it is valid Now, we allow the ACK update the window if the window is 0, and the seq/ack of it is valid. This is for the case that the receiver replies an zero-window ACK when it is under memory stress and can't queue the new data. Signed-off-by: Menglong Dong --- net/ipv4/tcp_input.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index aae485d0a3b6..f17cca362086 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -3525,7 +3525,7 @@ static inline bool tcp_may_update_window(const struct tcp_sock *tp, { return after(ack, tp->snd_una) || after(ack_seq, tp->snd_wl1) || - (ack_seq == tp->snd_wl1 && nwin > tp->snd_wnd); + (ack_seq == tp->snd_wl1 && (nwin > tp->snd_wnd || !nwin)); } /* If we update tp->snd_una, also update tp->bytes_acked */ From patchwork Mon Aug 7 13:45:47 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Menglong Dong X-Patchwork-Id: 13344274 X-Patchwork-Delegate: kuba@kernel.org Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0495C10952 for ; Mon, 7 Aug 2023 13:47:23 +0000 (UTC) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D547910EF; Mon, 7 Aug 2023 06:47:20 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id d9443c01a7336-1bc0d39b52cso29353785ad.2; Mon, 07 Aug 2023 06:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691416040; x=1692020840; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=hO5ffsMV1x2LeSF6TZmYSUDXcFSKo+pDvUEfomBe2w0=; b=m8bkI8THG1kg0LlHLz7Op4k5P/2LGhgnUZNsP4jww5zkGTS5mLQckMwLq5W8uPTkHL CJy7/c9Hg1u17DUGPLp1kXQxWSYpk0EWnP/D8ZCzVi0u9ZxbcKaZEbL7YolDWoPIecTH pLL4rw8Mp8eAfLlf51k+gQzJuIMVeEE1noTMRlCf34XgI//hv/7WRZ4OvaLVQsk3gALn 2xKEvSYqOKhTY+vW9mh9z1P3wvkBf3BBmA1SowChXtSMo0HFd757qVwHt7RD7Jn0U+5m R87IpLGfLKVCzIpzYyh7f9X8BN/ki4VsrI/62Zm1lt9NVsy/9kOjuFOO0l++vsx1SV9a nNOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691416040; x=1692020840; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hO5ffsMV1x2LeSF6TZmYSUDXcFSKo+pDvUEfomBe2w0=; b=QvtWckJ96ogN4dLSui7NooDmbxHBmyQQ2SN1cU/hM7f2MUjbb0rYsxQF7vRQ+PNaT/ Uv+DaW2l+QHY2uLiZDiNMqC8WIE8bhIHUen61IFbeugaf56tFxuCXDhMrL3A9Cyl68Vo PisnvLbLC/fbpcLSzopS7KU32GbkEKLHTl3JfBjUnOXysgPIhEppW8nmJyydnLGrLLsF Ap3qFrX9nxRg29xlOYt4WUSyF6yPxAf2z4sbSIa8QGakhlW0tQmo1JgHuG2ZNGDqwYqF qc5TKMEwub/QSB5Okb/G7iVOR+rD7l4cDMh+dT0toWJbVDiBt5QfZriTn1UD2l1JXEC1 jRAA== X-Gm-Message-State: AOJu0YxB8HWCDllhvmY+OcM4B8AMHfmd+MxvP+n0SJxRYvSnAtRS1hHK FSGF9bC3bZKyMh8YJAFp3uGkKAqBtWQvhPNXSrU= X-Google-Smtp-Source: AGHT+IHsQDpDGnSeuUYdXSPmTGGakiREXwsTWbkp15hPGMNkUKXmL3k+eyzM0T/sSXEjGASLoCJCaA== X-Received: by 2002:a17:903:2449:b0:1bc:1189:17f with SMTP id l9-20020a170903244900b001bc1189017fmr10891246pls.42.1691416040181; Mon, 07 Aug 2023 06:47:20 -0700 (PDT) Received: from localhost.localdomain ([203.205.141.23]) by smtp.gmail.com with ESMTPSA id h2-20020a170902704200b001b54a88e4a6sm6912097plt.51.2023.08.07.06.47.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Aug 2023 06:47:19 -0700 (PDT) From: menglong8.dong@gmail.com X-Google-Original-From: imagedong@tencent.com To: edumazet@google.com, ncardwell@google.com Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, dsahern@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Menglong Dong Subject: [PATCH net-next v2 3/3] net: tcp: fix unexcepted socket die when snd_wnd is 0 Date: Mon, 7 Aug 2023 21:45:47 +0800 Message-Id: <20230807134547.2782227-4-imagedong@tencent.com> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20230807134547.2782227-1-imagedong@tencent.com> References: <20230807134547.2782227-1-imagedong@tencent.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net X-Patchwork-Delegate: kuba@kernel.org From: Menglong Dong In tcp_retransmit_timer(), a window shrunk connection will be regarded as timeout if 'tcp_jiffies32 - tp->rcv_tstamp > TCP_RTO_MAX'. This is not right all the time. The retransmits will become zero-window probes in tcp_retransmit_timer() if the 'snd_wnd==0'. Therefore, the icsk->icsk_rto will come up to TCP_RTO_MAX sooner or later. However, the timer is not precise enough, as it base on timer wheel. Sorry that I am not good at timer, but I know the concept of time-wheel. The longer of the timer, the rougher it will be. So the timeout is not triggered after TCP_RTO_MAX, but 122877ms as I tested. Therefore, 'tcp_jiffies32 - tp->rcv_tstamp > TCP_RTO_MAX' is always true once the RTO come up to TCP_RTO_MAX, and the socket will die. Fix this by replacing the 'tcp_jiffies32' with '(u32)icsk->icsk_timeout', which is exact the timestamp of the timeout. Meanwhile, using "max(tp->retrans_stamp, tp->rcv_tstamp)" as the last updated timestamp in the receiving path, as "tp->rcv_tstamp" can restart from idle, then tp->rcv_tstamp could already be a long time (minutes or hours) in the past even on the first RTO. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/netdev/CADxym3YyMiO+zMD4zj03YPM3FBi-1LHi6gSD2XT8pyAMM096pg@mail.gmail.com/ Signed-off-by: Menglong Dong --- v2: - consider the case of the connection restart from idle, as Neal comment --- net/ipv4/tcp_timer.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c index d45c96c7f5a4..e4b2d8706cae 100644 --- a/net/ipv4/tcp_timer.c +++ b/net/ipv4/tcp_timer.c @@ -454,6 +454,14 @@ static void tcp_fastopen_synack_timer(struct sock *sk, struct request_sock *req) req->timeout << req->num_timeout, TCP_RTO_MAX); } +static bool tcp_rtx_probe0_timed_out(struct sock *sk) +{ + struct tcp_sock *tp = tcp_sk(sk); + u32 last_ts; + + last_ts = max(tp->retrans_stamp, tp->rcv_tstamp); + return inet_csk(sk)->icsk_timeout - last_ts > TCP_RTO_MAX; +} /** * tcp_retransmit_timer() - The TCP retransmit timeout handler @@ -519,7 +527,7 @@ void tcp_retransmit_timer(struct sock *sk) tp->snd_una, tp->snd_nxt); } #endif - if (tcp_jiffies32 - tp->rcv_tstamp > TCP_RTO_MAX) { + if (tcp_rtx_probe0_timed_out(sk)) { tcp_write_err(sk); goto out; }