Re: [PATCH 0/3] rcu: synchronize_rcu[_expedited]() related fixes

["Paul E. McKenney" <paulmck@kernel.org>]

On Tue, Mar 15, 2022 at 04:52:26PM +0100, Frederic Weisbecker wrote:
> On Mon, Mar 14, 2022 at 03:35:04PM -0700, Paul E. McKenney wrote:
> > On Mon, Mar 14, 2022 at 01:26:10PM -0700, Paul E. McKenney wrote:
> > > On Mon, Mar 14, 2022 at 02:37:35PM +0100, Frederic Weisbecker wrote:
> > > > 
> > > > A few fixes especially for expedited GP polling causing a stall on TREE07,
> > > > as reported by Paul.
> > > > 
> > > > We may still want to optimize start_poll_synchronize_rcu_expedited() on
> > > > UP-no-preempt but I think Paul may be implying this while doing other
> > > > fixes.
> > > > 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> > > > 	rcu/dev
> > > > 
> > > > HEAD: 6e5fd7e614fd5c8f0fffeaa140b7ea697bfeb096
> > > > 
> > > > Thanks,
> > > > 	Frederic
> > > 
> > > I have pulled these in for review and testing, thank you!!!  I have
> > > started a ~90-minute test and will let you know how that goes.
> > 
> > And TREE05 doesn't like this much.  I get too-short grace periods.
> > TREE05 is unusual in being the one with the kernel build with
> > CONFIG_PREEMPT_NONE=y but also with CONFIG_PREEMPT_DYNAMIC=n.
> > 
> > Running tests of the commits individually.
> 
> Ouch, please test the following:
> 
> ---
> >From f180dd5809d2c3a6343cbd13f244b7b7f110a506 Mon Sep 17 00:00:00 2001
> From: Frederic Weisbecker <frederic@kernel.org>
> Date: Tue, 15 Mar 2022 16:33:38 +0100
> Subject: [PATCH] rcutorture: Call preempt_schedule() through static call/key

You know, it would have been quite some time before I would have thought
to suspect that code, so thank you very much for chasing this down!

I have pulled it in, reverted my reversion of your patch 3/3, and started
a moderate set of tests.

							Thanx, Paul

> rcutorture sometimes want to trigger a random scheduler preemption call
> while simulating a read delay. However a direct call to
> preempt_schedule() is not desirable because it bypasses the static
> call/key filter used by CONFIG_PREEMPT_DYNAMIC. This breaks the
> no-preempt assumption in case the dynamic preemption mode is "none".
> 
> For example rcu_blocking_is_gp() is fooled and abbreviates grace periods
> when the CPU runs in no-preempt UP mode.
> 
> Fix this with making torture_preempt_schedule() to call through
> preempt dynamic static call/key.
> 
> Reported-by: Paul E. McKenney <paulmck@kernel.org>
> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> ---
>  include/linux/torture.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/torture.h b/include/linux/torture.h
> index 63fa4196e51c..7038104463e4 100644
> --- a/include/linux/torture.h
> +++ b/include/linux/torture.h
> @@ -118,7 +118,7 @@ void _torture_stop_kthread(char *m, struct task_struct **tp);
>  	_torture_stop_kthread("Stopping " #n " task", &(tp))
>  
>  #ifdef CONFIG_PREEMPTION
> -#define torture_preempt_schedule() preempt_schedule()
> +#define torture_preempt_schedule() __preempt_schedule()
>  #else
>  #define torture_preempt_schedule()	do { } while (0)
>  #endif
> -- 
> 2.25.1
>