linux-kernel - Re: [PATCH] rcutorture: Use the barrier operation corresponding to rcutorture.torture

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 1 Aug 2022 16:10:29 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Zqiang <qiang1.zhang@...el.com>
Cc:     frederic@...nel.org, quic_neeraju@...cinc.com, rcu@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rcutorture: Use the barrier operation corresponding to
 rcutorture.torture_type

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@...el.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@...el.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@...el.com>
    Signed-off-by: Paul E. McKenney <paulmck@...nel.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]);