Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp2022487rwn; Fri, 16 Sep 2022 04:41:45 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5/++44Xrrt/4x2EkimSA8jLNRsVguVUCZN9IRK0H/oWcMzADwZAduCZRgzVWmFMN99MfmD X-Received: by 2002:a17:902:da81:b0:178:1d8b:6cb4 with SMTP id j1-20020a170902da8100b001781d8b6cb4mr4388246plx.43.1663328505718; Fri, 16 Sep 2022 04:41:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663328505; cv=none; d=google.com; s=arc-20160816; b=oGWRtdXARD8+wIbMxLtkzayuajurjx8MqJoMKkG/1aWcVGI2vmh1RGvAJPy6xdCC+6 8X2mc8Kb6FPmqgYWlO9phKAs/R6Us1w5040jwQZtrajGEe0vI1kcYrUzBogI/AeoGdtw LjQobd2dS1ckBEBipmvV5AlGmvHVzDJkYrcsETzOlxxhYUSvFl8aT79nBxtAMm+7nD8W S6PcBAYboO52AjwxvIWZ+sLHbm5szHY6BpEfSzALEHGJtu1OXHkF45o8/1Lh6wuWkgZC 79zquS1/N09irxz+940q6pW2SW6CxxOVohbAAOrmMk0yl6Ytgt1He0E3BhgeBs/0PbhU k2Uw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ZERRlS8UjZCnSAyyu7sAMCBLq/4DSJjpVle8jhBcA+M=; b=PkrZc2dSNqzXhY3sBK96NxYuIydDN7hU9zLa+38otFVa3mgPtbIe6EBEbSzihPTSJr FOZPhuWwVBEbT9WMnBBClLgtv/lkjZwPaOvSyr+pmn1VzupCW7cmU27FEbIf2XIdKiOB 1NGKVGf9HZog25FLxrxoqLAupzuLu5yEnA5vrF2yyMQDa5S34K4NaIsJ3o/6La+wp7fx AR9OhEjGilbi/fkqsbAalfE0g7YogYDa94SMpuESVwZ5lr2KavYm/Xlxmzydc1VZP+rf Y35csssR0LnkLIUOSk/Ns0uf6JUaZxxo+LQ8LewbBkA5iAwr2quCQHHjfDvS/iZKGXkl +9mA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Dl5ZPEbM; 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=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f127-20020a636a85000000b0043997c73895si4571912pgc.571.2022.09.16.04.41.34; Fri, 16 Sep 2022 04:41:45 -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=@kernel.org header.s=k20201202 header.b=Dl5ZPEbM; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232070AbiIPLL0 (ORCPT + 99 others); Fri, 16 Sep 2022 07:11:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54132 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231233AbiIPLLG (ORCPT ); Fri, 16 Sep 2022 07:11:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2997DFEB; Fri, 16 Sep 2022 04:09:54 -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 dfw.source.kernel.org (Postfix) with ESMTPS id BAF8862ADB; Fri, 16 Sep 2022 11:09:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C3ACBC433D6; Fri, 16 Sep 2022 11:09:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1663326593; bh=9VS/3wMkl587CsdJR8VIgh2oPhWdCpR7xhEubqM7rAI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Dl5ZPEbM7/iEGoNbiiUTZi6mnLeEtiiF9eA9N+ZVp7HiyjrM0xM57phE5UACB68K8 BKW6LA1PcvuG6rFWOZcjoi+Og4S/1Kb5m0Ascqg3cf0U0A1+Y+AXlefoppgI225+6o alr1BzcAucGPitgRgT51sf+cWMW83RvqLZROkLacT2UdN/lnmNRvzFZxP5EcxdJV3h H6YSXkTmJnUtnBNUjr2Ouq8OmQ+nJJNUZoPAHSx+vsLwF7klsydwFiFRNvAdmImTOp NrcTr6J4EN0qwjLUIltOe6HgN80cQMeChU1OXuInsYdrRVifHIQF8in/07N63xK5hD L9nPgXqDNkS3w== Date: Fri, 16 Sep 2022 13:09:49 +0200 From: Frederic Weisbecker To: "Joel Fernandes (Google)" Cc: linux-kernel@vger.kernel.org, Josh Triplett , Lai Jiangshan , Mathieu Desnoyers , Neeraj Upadhyay , "Paul E. McKenney" , rcu@vger.kernel.org, Steven Rostedt Subject: Re: [PATCH rcu/next 2/3] rcu: Move trace_rcu_callback() before bypassing Message-ID: <20220916110949.GB25456@lothringen> References: <20220915001419.55617-1-joel@joelfernandes.org> <20220915001419.55617-3-joel@joelfernandes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220915001419.55617-3-joel@joelfernandes.org> X-Spam-Status: No, score=-7.1 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 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, Sep 15, 2022 at 12:14:18AM +0000, Joel Fernandes (Google) wrote: > If any CB is queued into the bypass list, then trace_rcu_callback() does > not show it. This makes it not clear when a callback was actually > queued, as you only end up getting a trace_rcu_invoke_callback() trace. > Fix it by moving trace_rcu_callback() before > trace_rcu_nocb_try_bypass(). > > Signed-off-by: Joel Fernandes (Google) > --- > kernel/rcu/tree.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index 5ec97e3f7468..9fe581be8696 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -2809,10 +2809,7 @@ void call_rcu(struct rcu_head *head, rcu_callback_t func) > } > > check_cb_ovld(rdp); > - if (rcu_nocb_try_bypass(rdp, head, &was_alldone, flags)) > - return; // Enqueued onto ->nocb_bypass, so just leave. > - // If no-CBs CPU gets here, rcu_nocb_try_bypass() acquired ->nocb_lock. > - rcu_segcblist_enqueue(&rdp->cblist, head); > + > if (__is_kvfree_rcu_offset((unsigned long)func)) > trace_rcu_kvfree_callback(rcu_state.name, head, > (unsigned long)func, > @@ -2821,6 +2818,11 @@ void call_rcu(struct rcu_head *head, rcu_callback_t func) > trace_rcu_callback(rcu_state.name, head, > rcu_segcblist_n_cbs(&rdp->cblist)); > > + if (rcu_nocb_try_bypass(rdp, head, &was_alldone, flags)) > + return; // Enqueued onto ->nocb_bypass, so just leave. > + // If no-CBs CPU gets here, rcu_nocb_try_bypass() acquired ->nocb_lock. > + rcu_segcblist_enqueue(&rdp->cblist, head); > + > trace_rcu_segcb_stats(&rdp->cblist, TPS("SegCBQueued")); > > /* Go handle any RCU core processing required. */ Two subtle changes induced here: * rcu_segcblist_n_cbs() is now read lockless. It's just tracing so no huge deal but still, if this races with callbacks invocation, we may on some rare occasion read stale numbers on traces while enqueuing (think about rcu_top for example) * trace_rcu_callback() will now show the number of callbacks _before_ enqueuing instead of _after_. Not sure if it matters, but sometimes tools rely on trace events. To avoid all that, how about a new trace_rcu_nocb_bypass() instead? Thanks.