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
---

Frederic Weisbecker (2):
      rcu: Fix expedited GP polling against UP/no-preempt environment
      rcu: Fix preemption mode check on synchronize_rcu[_expedited]()

Valentin Schneider (1):
      preempt/dynamic: Introduce preempt mode accessors


 include/linux/sched.h | 16 +++++++++++++++
 kernel/rcu/tree.c     |  2 +-
 kernel/rcu/tree_exp.h | 57 +++++++++++++++++++++++++++++++--------------------
 kernel/sched/core.c   | 11 ++++++++++
 4 files changed, 63 insertions(+), 23 deletions(-)

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.

> ---
> 
> Frederic Weisbecker (2):
>       rcu: Fix expedited GP polling against UP/no-preempt environment

I have some concerns with this one due to the fact that it acquires locks
in cases where the old code would not.  (I did have problems with this
in both recent SRCU changes and the normal-grace-period counterpart to
this series.)

But let's see what rcutorture and kbuild test robot think about it.

>       rcu: Fix preemption mode check on synchronize_rcu[_expedited]()

This one looks good.

> Valentin Schneider (1):
>       preempt/dynamic: Introduce preempt mode accessors

I am guessing that this one is a compact placeholder for my convenience
(in which case thank you!).  I will be marking it "EXP" on my next rebase.

							Thanx, Paul

>  include/linux/sched.h | 16 +++++++++++++++
>  kernel/rcu/tree.c     |  2 +-
>  kernel/rcu/tree_exp.h | 57 +++++++++++++++++++++++++++++++--------------------
>  kernel/sched/core.c   | 11 ++++++++++
>  4 files changed, 63 insertions(+), 23 deletions(-)

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.

							Thanx, Paul

> > ---
> > 
> > Frederic Weisbecker (2):
> >       rcu: Fix expedited GP polling against UP/no-preempt environment
> 
> I have some concerns with this one due to the fact that it acquires locks
> in cases where the old code would not.  (I did have problems with this
> in both recent SRCU changes and the normal-grace-period counterpart to
> this series.)
> 
> But let's see what rcutorture and kbuild test robot think about it.
> 
> >       rcu: Fix preemption mode check on synchronize_rcu[_expedited]()
> 
> This one looks good.
> 
> > Valentin Schneider (1):
> >       preempt/dynamic: Introduce preempt mode accessors
> 
> I am guessing that this one is a compact placeholder for my convenience
> (in which case thank you!).  I will be marking it "EXP" on my next rebase.
> 
> 							Thanx, Paul
> 
> >  include/linux/sched.h | 16 +++++++++++++++
> >  kernel/rcu/tree.c     |  2 +-
> >  kernel/rcu/tree_exp.h | 57 +++++++++++++++++++++++++++++++--------------------
> >  kernel/sched/core.c   | 11 ++++++++++
> >  4 files changed, 63 insertions(+), 23 deletions(-)

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

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

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
>