From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6449C4332F for ; Fri, 18 Nov 2022 00:24:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234931AbiKRAYG (ORCPT ); Thu, 17 Nov 2022 19:24:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37724 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234418AbiKRAYD (ORCPT ); Thu, 17 Nov 2022 19:24:03 -0500 Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6ED4167F68 for ; Thu, 17 Nov 2022 16:24:01 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id a27so2230868qtw.10 for ; Thu, 17 Nov 2022 16:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=PQALVvBpG9Tgm4QJd1bZefWDruQZ7+FZQSohOhIfB6E=; b=WdVSFjUXoLnDIwsaQd/YCFQYOfKxlJH+t+28yswVvhFD8+/5OsWHv3c1mXajHuV7TN FB8/dQlrzdu9V/hdN5EfH52HdApuaiULyJCJHTWp/BL0H8/WaFqlz1coGPm6H+qr8P8h qgR+O7JetxtHeRm8yq7fn2IdswK27/UJQM/LQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PQALVvBpG9Tgm4QJd1bZefWDruQZ7+FZQSohOhIfB6E=; b=wNZApNN6tzrP2ymA/cydIXYiVqvinitscE3Xo6+GIHLiSnkHZ1iR1uLRmDAsI0rkg1 /xQbBEmxdOCqV0axm2Aud6rFfZhgipjD8i89DaesvXBzxqeGjZqaDpLEsNa4hKqJQ8IF +dqzfnQgb5Szy2DJa1TeA6ScrKBiRZOcaEy75dvPaMRoAlFhBqleWOKpIvIRac/sUo5f HHbLih1+Zac4NvwxnboU9rDgkuUD2uWme0mNHXo3nTHl8RzJAStWvxshZK9/OE621Xf+ 1mna39J3gc0m7DhugYsVB8mNBlmWSxN2rSasO/iqYWr6gKheLFyPZjrVa1J6EkHOpO4b z7qA== X-Gm-Message-State: ANoB5pnuAvcNB091mQtFO0jGXwqoq4Bg+XGEy0JO6oSF5x6KaqNfzIfB kPCPet/m/Vwg3aMadN0ogCx9ZA== X-Google-Smtp-Source: AA0mqf5+rcoA5TgBVpqXybDxHbeal+yxGKYtKjh3sTqi9/GyE+4DuAC4zmbWbWOTZCcBVwClObMadA== X-Received: by 2002:a05:622a:428e:b0:3a5:5a43:b36b with SMTP id cr14-20020a05622a428e00b003a55a43b36bmr4654919qtb.407.1668731040558; Thu, 17 Nov 2022 16:24:00 -0800 (PST) Received: from localhost (228.221.150.34.bc.googleusercontent.com. [34.150.221.228]) by smtp.gmail.com with ESMTPSA id i15-20020a05620a248f00b006fa9d101775sm1476838qkn.33.2022.11.17.16.23.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Nov 2022 16:23:59 -0800 (PST) Date: Fri, 18 Nov 2022 00:23:59 +0000 From: Joel Fernandes 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 Subject: Re: [PATCH rcu/dev 1/3] net: Use call_rcu_flush() for qdisc_free_cb Message-ID: References: <20221117031551.1142289-1-joel@joelfernandes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Nov 17, 2022 at 01:44:12PM -0800, Eric Dumazet wrote: > On Wed, Nov 16, 2022 at 7:16 PM Joel Fernandes (Google) > wrote: > > > > In a networking test on ChromeOS, we find that using the new CONFIG_RCU_LAZY > > causes a networking test to fail in the teardown phase. > > > > The failure happens during: ip netns del > > > > Using ftrace, I found the callbacks it was queuing which this series fixes. Use > > call_rcu_flush() to revert to the old behavior. With that, the test passes. > > > > Signed-off-by: Joel Fernandes (Google) > > --- > > net/sched/sch_generic.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c > > index a9aadc4e6858..63fbf640d3b2 100644 > > --- a/net/sched/sch_generic.c > > +++ b/net/sched/sch_generic.c > > @@ -1067,7 +1067,7 @@ static void qdisc_destroy(struct Qdisc *qdisc) > > > > trace_qdisc_destroy(qdisc); > > > > - call_rcu(&qdisc->rcu, qdisc_free_cb); > > + call_rcu_flush(&qdisc->rcu, qdisc_free_cb); > > } > > I took a look at this one. > > qdisc_free_cb() is essentially freeing : Some per-cpu memory, and the > 'struct Qdisc' > > I do not see why we need to force a flush for this (small ?) piece of memory. Indeed! Just tested and dropping this one still makes the test pass. I believe this patch was papering over the issues fixed by the other patches, so it stuck. I will drop this one and move over to trying your suggestions for 2/3. Thanks for taking a look, - Joel