* [PATCH 5.10] rcu: Do not report strict GPs for outgoing CPUs
@ 2022-02-15 2:23 Zhen Lei
2022-02-17 18:48 ` Greg Kroah-Hartman
0 siblings, 1 reply; 2+ messages in thread
From: Zhen Lei @ 2022-02-15 2:23 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable; +Cc: Zhen Lei, Paul E . McKenney
From: "Paul E. McKenney" <paulmck@kernel.org>
[ Upstream commit bfb3aa735f82c8d98b32a669934ee7d6b346264d ]
An outgoing CPU is marked offline in a stop-machine handler and most
of that CPU's services stop at that point, including IRQ work queues.
However, that CPU must take another pass through the scheduler and through
a number of CPU-hotplug notifiers, many of which contain RCU readers.
In the past, these readers were not a problem because the outgoing CPU
has interrupts disabled, so that rcu_read_unlock_special() would not
be invoked, and thus RCU would never attempt to queue IRQ work on the
outgoing CPU.
This changed with the advent of the CONFIG_RCU_STRICT_GRACE_PERIOD
Kconfig option, in which rcu_read_unlock_special() is invoked upon exit
from almost all RCU read-side critical sections. Worse yet, because
interrupts are disabled, rcu_read_unlock_special() cannot immediately
report a quiescent state and will therefore attempt to defer this
reporting, for example, by queueing IRQ work. Which fails with a splat
because the CPU is already marked as being offline.
But it turns out that there is no need to report this quiescent state
because rcu_report_dead() will do this job shortly after the outgoing
CPU makes its final dive into the idle loop. This commit therefore
makes rcu_read_unlock_special() refrain from queuing IRQ work onto
outgoing CPUs.
Fixes: 44bad5b3cca2 ("rcu: Do full report for .need_qs for strict GPs")
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
kernel/rcu/tree_plugin.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 6ed153f226b3925..244f32e98360fdf 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -628,7 +628,7 @@ static void rcu_read_unlock_special(struct task_struct *t)
set_tsk_need_resched(current);
set_preempt_need_resched();
if (IS_ENABLED(CONFIG_IRQ_WORK) && irqs_were_disabled &&
- !rdp->defer_qs_iw_pending && exp) {
+ !rdp->defer_qs_iw_pending && exp && cpu_online(rdp->cpu)) {
// Get scheduler to re-evaluate and call hooks.
// If !IRQ_WORK, FQS scan will eventually IPI.
init_irq_work(&rdp->defer_qs_iw,
--
2.26.0.106.g9fadedd
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH 5.10] rcu: Do not report strict GPs for outgoing CPUs
2022-02-15 2:23 [PATCH 5.10] rcu: Do not report strict GPs for outgoing CPUs Zhen Lei
@ 2022-02-17 18:48 ` Greg Kroah-Hartman
0 siblings, 0 replies; 2+ messages in thread
From: Greg Kroah-Hartman @ 2022-02-17 18:48 UTC (permalink / raw)
To: Zhen Lei; +Cc: stable, Paul E . McKenney
On Tue, Feb 15, 2022 at 10:23:19AM +0800, Zhen Lei wrote:
> From: "Paul E. McKenney" <paulmck@kernel.org>
>
> [ Upstream commit bfb3aa735f82c8d98b32a669934ee7d6b346264d ]
>
> An outgoing CPU is marked offline in a stop-machine handler and most
> of that CPU's services stop at that point, including IRQ work queues.
> However, that CPU must take another pass through the scheduler and through
> a number of CPU-hotplug notifiers, many of which contain RCU readers.
> In the past, these readers were not a problem because the outgoing CPU
> has interrupts disabled, so that rcu_read_unlock_special() would not
> be invoked, and thus RCU would never attempt to queue IRQ work on the
> outgoing CPU.
>
> This changed with the advent of the CONFIG_RCU_STRICT_GRACE_PERIOD
> Kconfig option, in which rcu_read_unlock_special() is invoked upon exit
> from almost all RCU read-side critical sections. Worse yet, because
> interrupts are disabled, rcu_read_unlock_special() cannot immediately
> report a quiescent state and will therefore attempt to defer this
> reporting, for example, by queueing IRQ work. Which fails with a splat
> because the CPU is already marked as being offline.
>
> But it turns out that there is no need to report this quiescent state
> because rcu_report_dead() will do this job shortly after the outgoing
> CPU makes its final dive into the idle loop. This commit therefore
> makes rcu_read_unlock_special() refrain from queuing IRQ work onto
> outgoing CPUs.
>
> Fixes: 44bad5b3cca2 ("rcu: Do full report for .need_qs for strict GPs")
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> Cc: Jann Horn <jannh@google.com>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> ---
> kernel/rcu/tree_plugin.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index 6ed153f226b3925..244f32e98360fdf 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -628,7 +628,7 @@ static void rcu_read_unlock_special(struct task_struct *t)
> set_tsk_need_resched(current);
> set_preempt_need_resched();
> if (IS_ENABLED(CONFIG_IRQ_WORK) && irqs_were_disabled &&
> - !rdp->defer_qs_iw_pending && exp) {
> + !rdp->defer_qs_iw_pending && exp && cpu_online(rdp->cpu)) {
> // Get scheduler to re-evaluate and call hooks.
> // If !IRQ_WORK, FQS scan will eventually IPI.
> init_irq_work(&rdp->defer_qs_iw,
> --
> 2.26.0.106.g9fadedd
>
Now queued up, thanks.
greg k-h
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-02-17 18:48 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-15 2:23 [PATCH 5.10] rcu: Do not report strict GPs for outgoing CPUs Zhen Lei
2022-02-17 18:48 ` Greg Kroah-Hartman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.