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@xxxxxxxxx>
>
> >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@xxxxxxxxx>
> 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@xxxxxxxxx>
> Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx>
>
> 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);
