Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp156182ybg; Tue, 2 Jun 2020 19:44:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyUDnrrajtZ3CgqwX8marrRIuylMg2Ly/vFg/axEs5Cg5NQ9DRKZLqQtQDHFqUmwaoYSsnh X-Received: by 2002:a50:cfc4:: with SMTP id i4mr28605044edk.252.1591152284093; Tue, 02 Jun 2020 19:44:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591152284; cv=none; d=google.com; s=arc-20160816; b=R3VlM0H+emGB6vfffEvyQz7wa1/bNedgegm8nZUUoAVG8/GZ8cqlqpPhO214VPW28C sNLxoiGXRMGCcrn+MnrTS6qMVNG0QziqiE+/1ZLqIeftpooNQVgPcHmGun56Y4r/tHVV G8gWt43RZMoLfm+hjGNF5r0gu31+V3Y39SW+aTuasPXahUHAl0HzF6JD95g5dJUvuQOb T5131OuqPTZ58GDXh54oagvb+V9DRWjPznyLK5PttfJgGhN763hyEkurGhwv8twvrak8 uVRzqxV72D7JCa+Z+1CcH5CdxT937IAYxDQ0H9EVYteRfXW4ZnlQ3kCs2jYZ6fpasOvr UXHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=CFI1m1bXGZYKZMu3ppASc24ioDiu36YQQGgUMSxsWQI=; b=D39d1VHBUCVV027bzxvKNpkr5ih0Qh1XmJdjkVnGCDBNfnVA2SQup3Hf5YSYNX5W4T kOO5ORfdBeFO+l1ZPPJqYW7uSGzjibeMA4Ql8TQZ31uVwcWJXtco6yh7ZE7fhnYuSZoD 5+rYAoJsBo/+rSy7TqPiyj+kv/Ki1NwpQ18Bme6e99c00CdU1UBuoNi6VpTSlAhxbmDI lJ4vunKS/w1bR6u7JuCooCZQBcRPO+hFeCgxC4Hm0lcIhNxqZ4s+BbbndiuddPr45v0+ uqJnTdOBppwCMPjUoDUbFAe+ms/wrJ6l60YiHl0ZezbGS/sHhwQ4Hh54FoyhwCVFw7lY aF2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=c9WYIlS6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c4si377893ejm.465.2020.06.02.19.44.21; Tue, 02 Jun 2020 19:44:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=c9WYIlS6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725906AbgFCCmV (ORCPT + 99 others); Tue, 2 Jun 2020 22:42:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725794AbgFCCmU (ORCPT ); Tue, 2 Jun 2020 22:42:20 -0400 Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CA37C08C5C0; Tue, 2 Jun 2020 19:42:19 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id a25so786343ljp.3; Tue, 02 Jun 2020 19:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CFI1m1bXGZYKZMu3ppASc24ioDiu36YQQGgUMSxsWQI=; b=c9WYIlS6PxKJJ2EHnd7jvE8gIGL2qlHjjyJRJqsFW73FDRISPapGPm0n74iGH/I4BU BOXAPIcDN6qJr0qSGyzl6+8oMsT/KkwWX5jwqCDzBQJGaCkLX4G3tfe80xrRw5j80mlk hzK6BK48EzBqJoAnYOyIFixwCozmdGOhNwMLYeR3DYPJAIhJVniL8FyKoOhXbOBLjZb4 DmjKSaXgs89smvy8HhmU874l0UAIG+junoxNOS7b9FPQd6+Prwk/Xvam6+MXOHMZu3BP lCl0QHMTfFhYGdnZDvd8UTzJprcJON1qgei9L33eU857V4TmXKOiarWKlZV20k9Sj1w4 B9QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CFI1m1bXGZYKZMu3ppASc24ioDiu36YQQGgUMSxsWQI=; b=mb8mUKHT3pQRmod/Gh9sS4pof60qbcdIzDdLCm/7aGXm+PNEG/9rqIjdWfkiETBYB5 aQ4c5B221QnunFwGG2gIAzAnhLt4LTmJEhvp8iTI7eTJhplTJIyF/1RTIT6E3CuJrzAx zBKbDhFXgAAJYubCG/U0wuFEb7AtkV5Nx0J+7NwQvxpDZCyiCidM/hFEUwSzPlwB2lQo CqHD20kICKEx3Fj2Hwq3n1M91ainprzbHkxwr/R4T03m7Z5sgZiyy9cFHFh6AsRxBkEN 8noTUkL4b/jMWtbSw/Qx/oihhkQikqbGu7dCfoprgPUiS4UFMyanBOy5kljB5K+0xwXf VaHA== X-Gm-Message-State: AOAM530R4TmAiHNaG/iEo7zZq0P/qNNHmE5NrO/JiLhkPCBmKvMJHiIr 8n9mKXm7iLQSgep8WsfTmASCW8GvM211Vvo/PrE= X-Received: by 2002:a2e:750d:: with SMTP id q13mr892413ljc.448.1591152137654; Tue, 02 Jun 2020 19:42:17 -0700 (PDT) MIME-Version: 1.0 References: <20200602080425.93712-1-kerneljasonxing@gmail.com> In-Reply-To: From: Jason Xing Date: Wed, 3 Jun 2020 10:41:41 +0800 Message-ID: Subject: Re: [PATCH] tcp: fix TCP socks unreleased in BBR mode To: Eric Dumazet Cc: David Miller , Alexey Kuznetsov , Hideaki YOSHIFUJI , netdev , LKML , liweishi@kuaishou.com, Shujin Li Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I agree with you. The upstream has already dropped and optimized this part (commit 864e5c090749), so it would not happen like that. However the old kernels like LTS still have the problem which causes large-scale crashes on our thousands of machines after running for a long while. I will send the fix to the correct tree soon :) Thanks again, Jason On Wed, Jun 3, 2020 at 10:29 AM Eric Dumazet wrote: > > On Tue, Jun 2, 2020 at 6:53 PM Jason Xing wrote: > > > > Hi Eric, > > > > I'm sorry that I didn't write enough clearly. We're running the > > pristine 4.19.125 linux kernel (the latest LTS version) and have been > > haunted by such an issue. This patch is high-important, I think. So > > I'm going to resend this email with the [patch 4.19] on the headline > > and cc Greg. > > Yes, please always give for which tree a patch is meant for. > > Problem is that your patch is not correct. > In these old kernels, tcp_internal_pacing() is called _after_ the > packet has been sent. > It is too late to 'give up pacing' > > The packet should not have been sent if the pacing timer is queued > (otherwise this means we do not respect pacing) > > So the bug should be caught earlier. check where tcp_pacing_check() > calls are missing. > > > > > > > > > Thanks, > > Jason > > > > On Tue, Jun 2, 2020 at 9:05 PM Eric Dumazet wrote: > > > > > > On Tue, Jun 2, 2020 at 1:05 AM wrote: > > > > > > > > From: Jason Xing > > > > > > > > TCP socks cannot be released because of the sock_hold() increasing the > > > > sk_refcnt in the manner of tcp_internal_pacing() when RTO happens. > > > > Therefore, this situation could increase the slab memory and then trigger > > > > the OOM if the machine has beening running for a long time. This issue, > > > > however, can happen on some machine only running a few days. > > > > > > > > We add one exception case to avoid unneeded use of sock_hold if the > > > > pacing_timer is enqueued. > > > > > > > > Reproduce procedure: > > > > 0) cat /proc/slabinfo | grep TCP > > > > 1) switch net.ipv4.tcp_congestion_control to bbr > > > > 2) using wrk tool something like that to send packages > > > > 3) using tc to increase the delay in the dev to simulate the busy case. > > > > 4) cat /proc/slabinfo | grep TCP > > > > 5) kill the wrk command and observe the number of objects and slabs in TCP. > > > > 6) at last, you could notice that the number would not decrease. > > > > > > > > Signed-off-by: Jason Xing > > > > Signed-off-by: liweishi > > > > Signed-off-by: Shujin Li > > > > --- > > > > net/ipv4/tcp_output.c | 3 ++- > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c > > > > index cc4ba42..5cf63d9 100644 > > > > --- a/net/ipv4/tcp_output.c > > > > +++ b/net/ipv4/tcp_output.c > > > > @@ -969,7 +969,8 @@ static void tcp_internal_pacing(struct sock *sk, const struct sk_buff *skb) > > > > u64 len_ns; > > > > u32 rate; > > > > > > > > - if (!tcp_needs_internal_pacing(sk)) > > > > + if (!tcp_needs_internal_pacing(sk) || > > > > + hrtimer_is_queued(&tcp_sk(sk)->pacing_timer)) > > > > return; > > > > rate = sk->sk_pacing_rate; > > > > if (!rate || rate == ~0U) > > > > -- > > > > 1.8.3.1 > > > > > > > > > > Hi Jason. > > > > > > Please do not send patches that do not apply to current upstream trees. > > > > > > Instead, backport to your kernels the needed fixes. > > > > > > I suspect that you are not using a pristine linux kernel, but some > > > heavily modified one and something went wrong in your backports. > > > Do not ask us to spend time finding what went wrong. > > > > > > Thank you.