Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2424844rwb; Thu, 17 Nov 2022 10:31:54 -0800 (PST) X-Google-Smtp-Source: AA0mqf4OoEJJDio9IGElBMbdhAHTmaCeaaFC11hnLRUB8usu4fnglpEDweSgghqXtibGdm9CGJCz X-Received: by 2002:a17:906:2896:b0:7a1:e4c2:fb0a with SMTP id o22-20020a170906289600b007a1e4c2fb0amr3247600ejd.101.1668709914181; Thu, 17 Nov 2022 10:31:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668709914; cv=none; d=google.com; s=arc-20160816; b=SHelQDg+xvbLuCGLqpxqhq8I/FtCfnc5mLLqP4KLkLy9cj3XS85Ao9z6GC6BKAvHbV Csd+OCytclDI5NGmr8JjdRh0Jl9jOi5LCxWRhvYli9flxMyuGW2vU0wcuh6Xty3GirJ2 zvG982qWIEj96xzaCns4NcbNuqG56z9QBmC3pC1EDk37ZDX9yLvTPZNZXubtX9itQTVG J4vvlL00BOCb9pCzaBszg5bRd6GpM6xMUqITWs8OGV0SPmx5tjZGqdWxeaCejNoY4xl8 QY8CaMgnwePmqqUi1F2wC3d7ybr4lJcHVeIi6dBpTApTrBhUOjmmJepVGOjK8SM1fofM t4IQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=tLa0hKjA9GOfaZoCfXhipYOOpTt3ShAuZvGXM0OsUH4=; b=C7KR59ghpIJU4xnrl+Q0yhBeh8TU9Bw6bkbslCnSCOt5Zj0TDRLvcFnk78YMHOG9sz 6u1ZUaX/tnyQbWjo/jUdhWO203+CNAp+BfDixTYlEjRwL58AWFRKm5keEkR9mvT/PBgF oSe/Lj2MjVznTeosbRgrsLUQoa6ZV3cfZuYa6h2Rkw22nPF1C2kZbth3Yg925R79e3Z4 AHUhJTCdNWc/K1wYu2BSocSKE/1BDzuZwHCAubOTieL3fVdATrVcuK0rRbxnrMMJZJ61 Io1nEVBaGFkRm2iXnAM0VuUD8V3+bJ3yIzIcSGqagxlV2iwxPlTQSmX/5zDINsjPzY46 DwLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b="cUWWJ9/H"; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y2-20020a056402440200b00457205ae2b5si1613723eda.358.2022.11.17.10.31.28; Thu, 17 Nov 2022 10:31:54 -0800 (PST) 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=@joelfernandes.org header.s=google header.b="cUWWJ9/H"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234739AbiKQSSl (ORCPT + 92 others); Thu, 17 Nov 2022 13:18:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239986AbiKQSS2 (ORCPT ); Thu, 17 Nov 2022 13:18:28 -0500 Received: from mail-oa1-x33.google.com (mail-oa1-x33.google.com [IPv6:2001:4860:4864:20::33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B310010A0 for ; Thu, 17 Nov 2022 10:18:27 -0800 (PST) Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-13be3ef361dso3080149fac.12 for ; Thu, 17 Nov 2022 10:18:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tLa0hKjA9GOfaZoCfXhipYOOpTt3ShAuZvGXM0OsUH4=; b=cUWWJ9/H7LmDougtNe1jq+6N61GxqO6ADwcq4fYEHFFP69BzrPVNN3yKre5HzqII3W v7EDJXHPQmdo8PzSGGPmhQ/1PZ8vQ0ERMesoMIpSzRg6d0QP6bL1P+EQGVpH5iRpuAhg WkPX528/HIVlFMT7JzFWOr1bXBnTKbHJ7ut1c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tLa0hKjA9GOfaZoCfXhipYOOpTt3ShAuZvGXM0OsUH4=; b=be3eIvrTBlfTg4in6k4+xXPb9bUPevWSwdQpyuP7QhNpJusdegQHfMCzwdC1GGrEgp teSwz9wWbIRmSNkPeNYrsDBxvzPkjZiTvnwtRCfQJ2R2y6pXQG/qMuDK+uDzmVkYtnNM WCW/DkSyqV0sWItHlOP9luc31uNHckrJ5KZeznN5IyaqRRTUAxbTtNcH32O049O9RtG+ Cm5vFEyNvWspWEBuHZFe0RvwMpdRnXdrShoXRm9qXdT0FPKAZ2VXWFD01TAQY8u/1G/s ls9dnB1wyn4ht5FULhqd+16mxJ8yZSvJ4eF8/JYN6Ghu0dkatpOxDJ7PxWGgzsfYTb8F 7Tng== X-Gm-Message-State: ANoB5pml6c2tyLLcabSw5MemLX1xrLnbw4gpM6N892BiuTwvPxxK/Ak6 VzgiuOtvvcfQf8S2LPel85oKzLdqBsSXyNkHuZroew== X-Received: by 2002:a05:6870:bacb:b0:13a:dd16:9b83 with SMTP id js11-20020a056870bacb00b0013add169b83mr5018049oab.15.1668709104973; Thu, 17 Nov 2022 10:18:24 -0800 (PST) MIME-Version: 1.0 References: <20221117031551.1142289-1-joel@joelfernandes.org> <20221117031551.1142289-3-joel@joelfernandes.org> In-Reply-To: From: Joel Fernandes Date: Thu, 17 Nov 2022 18:18:14 +0000 Message-ID: Subject: Re: [PATCH rcu/dev 3/3] net: Use call_rcu_flush() for dst_destroy_rcu To: Eric Dumazet Cc: linux-kernel@vger.kernel.org, Cong Wang , David Ahern , "David S. Miller" , Hideaki YOSHIFUJI , Jakub Kicinski , Jamal Hadi Salim , Jiri Pirko , netdev@vger.kernel.org, Paolo Abeni , rcu@vger.kernel.org, rostedt@goodmis.org, paulmck@kernel.org, fweisbec@gmail.com, jiejiang@google.com, Thomas Glexiner Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 17, 2022 at 5:49 PM Eric Dumazet wrote: > > On Thu, Nov 17, 2022 at 9:42 AM Joel Fernandes wrote: > > > > > > > Yes, I agree. Your comments here have not been useful (or respectful) > > so I am Ok with that. > > > > - Joel > > Well, I have discovered that some changes went in networking tree > without network maintainers being involved nor CCed. > > What can I say ? > > It seems I have no say, right ? Sorry, I take responsibility for that. FWIW, the rxrpc change is not yet in Linus's tree. Also FWIW, the rxrpc case came up because we detected that it does a scheduler wakeup from the callback. We did both static and dynamic testing to identify callbacks that do wakeups throughout the kernel (kernel patch available on request), as the pattern observed is things doing wakeups typically are for use cases that are not freeing memory but something blocking, similar to synchronize_rcu(). So it was a "trivial/obvious" change to make for rxrpc which I might have assumed did not need much supervision because it just reverts that API to the old behavior -- still probably no excuse. Again, we can talk this out no problem. But I would strongly recommend not calling it "crazy thing", as we did all due diligence for almost a year (talking about it at LPC, working through various code paths and bugs, 4 different patch redesigns on the idea (including the opt-in that you are bringing up), including a late night debugging session to figure this out etc). Just to clarify, I know you review/maintain a lot of the networking code and I really appreciate that (not praising just for the sake). And I care about the kernel too, just like you. thanks, - Joel > commit f32846476afbe1f296c41d036219178b3dfb6a9d > Author: Joel Fernandes (Google) > Date: Sun Oct 16 16:23:04 2022 +0000 > > rxrpc: Use call_rcu_flush() instead of call_rcu() > > call_rcu() changes to save power may cause slowness. Use the > call_rcu_flush() API instead which reverts to the old behavior. > > We find this via inspection that the RCU callback does a wakeup of a > thread. This usually indicates that something is waiting on it. To be > safe, let us use call_rcu_flush() here instead. > > Signed-off-by: Joel Fernandes (Google) > Signed-off-by: Paul E. McKenney > > diff --git a/net/rxrpc/conn_object.c b/net/rxrpc/conn_object.c > index 22089e37e97f0628f780855f9e219e5c33d4afa1..fdcfb509cc4434b0781b76623532aff9c854ce60 > 100644 > --- a/net/rxrpc/conn_object.c > +++ b/net/rxrpc/conn_object.c > @@ -253,7 +253,7 @@ void rxrpc_kill_connection(struct rxrpc_connection *conn) > * must carry a ref on the connection to prevent us getting here whilst > * it is queued or running. > */ > - call_rcu(&conn->rcu, rxrpc_destroy_connection); > + call_rcu_flush(&conn->rcu, rxrpc_destroy_connection); > } > > /*