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;
Date:   Mon, 1 Aug 2022 16:10:29 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Zqiang <qiang1.zhang@intel.com>
Cc:     frederic@kernel.org, quic_neeraju@quicinc.com, rcu@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rcutorture: Use the barrier operation corresponding to
 rcutorture.torture_type
Message-ID: <20220801231029.GB2860372@paulmck-ThinkPad-P17-Gen-1>
Reply-To: paulmck@kernel.org
References: <20220731105356.1741086-1-qiang1.zhang@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220731105356.1741086-1-qiang1.zhang@intel.com>
Precedence: bulk

On Sun, Jul 31, 2022 at 06:53:56PM +0800, Zqiang wrote:
> when the rcutorture.torture_type value is 'rcu', this is correct for
> invoke rcu_barrier() to wait all in-flight call_rcu() callbacks
> (rcu_torture_fwd_cb_cr()) complete in rcutorture_oom_notify(). but when
> the rcutorture.torture_type value is 'tasks-tracing', invoke rcu_barrier()
> won't wait all in-flight call_rcu_tasks_trace() callbacks complete, the
> rcu_barrier_tasks_trace() should be invoked.
> 
> This commit fix it by using barrier operation corresponding to
> rcutorture.torture_type to wait all in-flight rcu_torture_fwd_cb_cr()
> complete.
> 
> Signed-off-by: Zqiang <qiang1.zhang@intel.com>

Good catch, thank you!

I have done my usual wordsmithing as shown below.  Could you please
double-check it?

							Thanx, Paul

------------------------------------------------------------------------

commit f8c9027f9c81be92344996a51babaa5a23bd88db
Author: Zqiang <qiang1.zhang@intel.com>
Date:   Sun Jul 31 18:53:56 2022 +0800

    rcutorture: Use the barrier operation specified by cur_ops
    
    The rcutorture_oom_notify() function unconditionally invokes
    rcu_barrier(), which is OK when the rcutorture.torture_type value is
    "rcu", but unhelpful otherwise.  The purpose of these barrier calls is to
    wait for all outstanding callback-flooding callbacks to be invoked before
    cleaning up their data.  Using the wrong barrier function therefore
    risks arbitrary memory corruption.  Thus, this commit changes these
    rcu_barrier() calls into cur_ops->cb_barrier() to make things work when
    torturing non-vanilla flavors of RCU.
    
    Signed-off-by: Zqiang <qiang1.zhang@intel.com>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 7f13f2e5ed62f..7e7d54841613c 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -2638,12 +2638,12 @@ static int rcutorture_oom_notify(struct notifier_block *self,
 	for (i = 0; i < fwd_progress; i++)
 		ncbs += rcu_torture_fwd_prog_cbfree(&rfp[i]);
 	pr_info("%s: Freed %lu RCU callbacks.\n", __func__, ncbs);
-	rcu_barrier();
+	cur_ops->cb_barrier();
 	ncbs = 0;
 	for (i = 0; i < fwd_progress; i++)
 		ncbs += rcu_torture_fwd_prog_cbfree(&rfp[i]);
 	pr_info("%s: Freed %lu RCU callbacks.\n", __func__, ncbs);
-	rcu_barrier();
+	cur_ops->cb_barrier();
 	ncbs = 0;
 	for (i = 0; i < fwd_progress; i++)
 		ncbs += rcu_torture_fwd_prog_cbfree(&rfp[i]);