Messages in this thread | | | Date | Tue, 15 Mar 2022 09:53:52 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH 0/3] rcu: synchronize_rcu[_expedited]() related fixes |
| |
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 >
| |