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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 13 May 2022 07:14:45 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     "Zhang, Qiang1" <qiang1.zhang@...el.com>
Cc:     "frederic@...nel.org" <frederic@...nel.org>,
        "rcu@...r.kernel.org" <rcu@...r.kernel.org>,
        "linux-kernel@...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 01:17:16PM +0000, Zhang, Qiang1 wrote:
> 
> 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?
> 
> Hi Paul
> 
> I didn't think of  suitable test method,
> Can you provide me with a test method to test it, I will be happy to test.

Here is one possibility:

tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 60 --configs "TREE01 TREE02 TREE03 TREE04 TREE05 TREE07 TREE09 TREE10" --kconfig "CONFIG_NR_CPUS=4 CONFIG_RCU_STRICT_GRACE_PERIOD=y" --trust-make

On a 16-CPU system, this will do eight kernel builds and run about two
hours of testing.

							Thanx, Paul

> Thanks,
> Zqiang
> 
> >
> >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);