linux-kernel - Re: [PATCH] rcu: Direct boosting gp

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220513010651.GD1790663@paulmck-ThinkPad-P17-Gen-1>
Date:   Thu, 12 May 2022 18:06:51 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Zqiang <qiang1.zhang@...el.com>
Cc:     frederic@...nel.org, rcu@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rcu: Direct boosting gp_tasks for strict grace periods

On Fri, May 13, 2022 at 08:42:55AM +0800, Zqiang wrote:
> If the CONFIG_RCU_STRICT_GRACE_PERIOD option is enabled, the normal grace
> period will be treated as expedited grace period, the gp_tasks that block
> current grace period needs to be boosted unconditionally, therefore this
> commit adds Kconfig check in rcu_initiate_boost().
> 
> Signed-off-by: Zqiang <qiang1.zhang@...el.com>

Good eyes!  I have queued this for further review and testing, thank you!

What sorts of tests did you run on it?

As usual, I could not resist the urge to wordsmith, so could you please
check the version shown below?

							Thanx, Paul

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

commit 079e0f894c5d887c678f94332c1fa7287abfd6bc
Author: Zqiang <qiang1.zhang@...el.com>
Date:   Fri May 13 08:42:55 2022 +0800

    rcu: Immediately boost preempted readers for strict grace periods
    
    The intent of the CONFIG_RCU_STRICT_GRACE_PERIOD Konfig option is to
    cause normal grace periods to complete quickly in order to better catch
    errors resulting from improperly leaking pointers from RCU read-side
    critical sections.  However, kernels built with this option enabled still
    wait for some hundreds of milliseconds before boosting RCU readers that
    have been preempted within their current critical section.  The value
    of this delay is set by the CONFIG_RCU_BOOST_DELAY Kconfig option,
    which defaults to 500 milliseconds.
    
    This commit therefore causes kernels build with strict grace periods
    to ignore CONFIG_RCU_BOOST_DELAY.  This causes rcu_initiate_boost()
    to start boosting immediately after all CPUs on a given leaf rcu_node
    structure have passed through their quiescent states.
    
    Signed-off-by: Zqiang <qiang1.zhang@...el.com>
    Signed-off-by: Paul E. McKenney <paulmck@...nel.org>

diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 99cde4c947699..b4ab952f04ea6 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1159,7 +1159,8 @@ static void rcu_initiate_boost(struct rcu_node *rnp, unsigned long flags)
 	    (rnp->gp_tasks != NULL &&
 	     rnp->boost_tasks == NULL &&
 	     rnp->qsmask == 0 &&
-	     (!time_after(rnp->boost_time, jiffies) || rcu_state.cbovld))) {
+	     (!time_after(rnp->boost_time, jiffies) || rcu_state.cbovld ||
+	      IS_ENABLED(CONFIG_RCU_STRICT_GRACE_PERIOD)))) {
 		if (rnp->exp_tasks == NULL)
 			WRITE_ONCE(rnp->boost_tasks, rnp->gp_tasks);
 		raw_spin_unlock_irqrestore_rcu_node(rnp, flags);