Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1130846iob; Wed, 4 May 2022 15:31:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxTRuwStdHYFAexUwBibczepP1lT3RM2loj3A97278I0EeYZxcWNIai5wTSNiolmxDuq0UH X-Received: by 2002:a17:906:c110:b0:6e8:3a96:996a with SMTP id do16-20020a170906c11000b006e83a96996amr22735685ejc.216.1651703510821; Wed, 04 May 2022 15:31:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651703510; cv=none; d=google.com; s=arc-20160816; b=GMTJ5IH/u7kn8trnwNldwIqKPzf8j+WTP5OiZhRTsjd85VE7P4csuOxV8MCe6SLxml DFDnm2KgrHfdRmoVwTRaOeIsN8oLcUdXI1ChAdltZbFqKA48/ybzs8GVKVsqiIQ4dKTO xagmN6H39096ONPBjEl94gdWyaHOrF5Xcx4j43trUHwJ+xws/F5dsCZVloTBrFrTHAMr jOV9G8ram4z2LCjEmBxj10IGxKwjK+NZaYDVMuruu7Gb/LegXpp5Y9jeNPM/Oc3dMTal z19FATgKhplMURBZABZ3NSlaHTPAlZ631GXHvJeHtAV4KEdDTLH4QXQtp+a9l3xlNVFk cfFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=GsQoPsSS7XRt2mM6JQQ/7ajDsYqRiNvMEhZU6hwHatg=; b=YjIpDL0Zpji0SRlfDAsiq/Pcn+2yVeIMlBiLmbLRM9FDkC2YzSQcz80BqrJQ2vPn92 QgPKIlXIGtHeH8S9nCAAWbcRkBEW4zYt4h8j/GSwg1W6Ly1wv+tBs8b0q5mNJOP23guX +Qgl7NVXA3fyCw8Qunt7EviB8gs8zTOKoaX3sAJSCLR+UKZGXt6JoM64PDe3kw2+a0oJ E4LFC3h/iil+atANh+nBxcf1ndbr9SVnEoGAiy9WQugWfBQf5skOBhRqNvd4uCk4DpJe OcN8jeJuJDvx0pmDBgAvi/E06wLqUIiSeV1ABgWDZnsXBBZt+bRYv1tvCnyEjUVGglZQ eC/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=aKZg6lu3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ex17-20020a170907955100b006f3aa294b82si122059ejc.596.2022.05.04.15.31.26; Wed, 04 May 2022 15:31:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=aKZg6lu3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357431AbiEDRYW (ORCPT + 99 others); Wed, 4 May 2022 13:24:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51926 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356489AbiEDRFS (ORCPT ); Wed, 4 May 2022 13:05:18 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5F44351301; Wed, 4 May 2022 09:54:11 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 9D062B82792; Wed, 4 May 2022 16:54:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3DDB3C385A4; Wed, 4 May 2022 16:54:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1651683248; bh=xHjdodkM8imZA+Sq/nW+D5bW2iBF5yM/fZCpCyR5jek=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aKZg6lu3ROVWVlHZSln34skia1lS7UmIw4co0SNNzl/9GwJF8waxOmKd9VkB7G5Am Xfxco/Ga9zVfSMjuSsxxf5e4z39FXc6N9PQVk/8yf2gjurM+ZOZV/ouFbgRt0xDIou +oQhBSmubzKjwSSWFXRNLc+CTP762Dt1s+agQEWs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , Doug Porter , Soheil Hassas Yeganeh , Neal Cardwell , "David S. Miller" , Sasha Levin Subject: [PATCH 5.15 101/177] tcp: fix potential xmit stalls caused by TCP_NOTSENT_LOWAT Date: Wed, 4 May 2022 18:44:54 +0200 Message-Id: <20220504153102.232962663@linuxfoundation.org> X-Mailer: git-send-email 2.36.0 In-Reply-To: <20220504153053.873100034@linuxfoundation.org> References: <20220504153053.873100034@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Eric Dumazet [ Upstream commit 4bfe744ff1644fbc0a991a2677dc874475dd6776 ] I had this bug sitting for too long in my pile, it is time to fix it. Thanks to Doug Porter for reminding me of it! We had various attempts in the past, including commit 0cbe6a8f089e ("tcp: remove SOCK_QUEUE_SHRUNK"), but the issue is that TCP stack currently only generates EPOLLOUT from input path, when tp->snd_una has advanced and skb(s) cleaned from rtx queue. If a flow has a big RTT, and/or receives SACKs, it is possible that the notsent part (tp->write_seq - tp->snd_nxt) reaches 0 and no more data can be sent until tp->snd_una finally advances. What is needed is to also check if POLLOUT needs to be generated whenever tp->snd_nxt is advanced, from output path. This bug triggers more often after an idle period, as we do not receive ACK for at least one RTT. tcp_notsent_lowat could be a fraction of what CWND and pacing rate would allow to send during this RTT. In a followup patch, I will remove the bogus call to tcp_chrono_stop(sk, TCP_CHRONO_SNDBUF_LIMITED) from tcp_check_space(). Fact that we have decided to generate an EPOLLOUT does not mean the application has immediately refilled the transmit queue. This optimistic call might have been the reason the bug seemed not too serious. Tested: 200 ms rtt, 1% packet loss, 32 MB tcp_rmem[2] and tcp_wmem[2] $ echo 500000 >/proc/sys/net/ipv4/tcp_notsent_lowat $ cat bench_rr.sh SUM=0 for i in {1..10} do V=`netperf -H remote_host -l30 -t TCP_RR -- -r 10000000,10000 -o LOCAL_BYTES_SENT | egrep -v "MIGRATED|Bytes"` echo $V SUM=$(($SUM + $V)) done echo SUM=$SUM Before patch: $ bench_rr.sh 130000000 80000000 140000000 140000000 140000000 140000000 130000000 40000000 90000000 110000000 SUM=1140000000 After patch: $ bench_rr.sh 430000000 590000000 530000000 450000000 450000000 350000000 450000000 490000000 480000000 460000000 SUM=4680000000 # This is 410 % of the value before patch. Fixes: c9bee3b7fdec ("tcp: TCP_NOTSENT_LOWAT socket option") Signed-off-by: Eric Dumazet Reported-by: Doug Porter Cc: Soheil Hassas Yeganeh Cc: Neal Cardwell Acked-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- include/net/tcp.h | 1 + net/ipv4/tcp_input.c | 12 +++++++++++- net/ipv4/tcp_output.c | 1 + 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/include/net/tcp.h b/include/net/tcp.h index 71a9aeae693d..89d231477ef4 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -608,6 +608,7 @@ void tcp_synack_rtt_meas(struct sock *sk, struct request_sock *req); void tcp_reset(struct sock *sk, struct sk_buff *skb); void tcp_skb_mark_lost_uncond_verify(struct tcp_sock *tp, struct sk_buff *skb); void tcp_fin(struct sock *sk); +void tcp_check_space(struct sock *sk); /* tcp_timer.c */ void tcp_init_xmit_timers(struct sock *); diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 509f577869d4..6bd283b58bb8 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -5420,7 +5420,17 @@ static void tcp_new_space(struct sock *sk) INDIRECT_CALL_1(sk->sk_write_space, sk_stream_write_space, sk); } -static void tcp_check_space(struct sock *sk) +/* Caller made space either from: + * 1) Freeing skbs in rtx queues (after tp->snd_una has advanced) + * 2) Sent skbs from output queue (and thus advancing tp->snd_nxt) + * + * We might be able to generate EPOLLOUT to the application if: + * 1) Space consumed in output/rtx queues is below sk->sk_sndbuf/2 + * 2) notsent amount (tp->write_seq - tp->snd_nxt) became + * small enough that tcp_stream_memory_free() decides it + * is time to generate EPOLLOUT. + */ +void tcp_check_space(struct sock *sk) { /* pairs with tcp_poll() */ smp_mb(); diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index 369752f5f676..df413282fa2e 100644 --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -82,6 +82,7 @@ static void tcp_event_new_data_sent(struct sock *sk, struct sk_buff *skb) NET_ADD_STATS(sock_net(sk), LINUX_MIB_TCPORIGDATASENT, tcp_skb_pcount(skb)); + tcp_check_space(sk); } /* SND.NXT, if window was not shrunk or the amount of shrunk was less than one -- 2.35.1