From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
tglx@linutronix.de, mingo@kernel.org, jpoimboe@redhat.com,
mojha@codeaurora.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH HACK RFC] cpu: Prevent late-arriving interrupts from disrupting offline
Date: Tue, 4 Jun 2019 00:45:49 -0700 [thread overview]
Message-ID: <20190604074549.GP28207@linux.ibm.com> (raw)
In-Reply-To: <ea4887fb-cc77-59d4-3ba7-a59f5237ca40@arm.com>
On Mon, Jun 03, 2019 at 03:39:18PM +0200, Dietmar Eggemann wrote:
> On 6/3/19 1:44 PM, Mark Rutland wrote:
> >On Mon, Jun 03, 2019 at 10:38:48AM +0200, Peter Zijlstra wrote:
> >>On Sat, Jun 01, 2019 at 06:12:53PM -0700, Paul E. McKenney wrote:
> >>>Scheduling-clock interrupts can arrive late in the CPU-offline process,
> >>>after idle entry and the subsequent call to cpuhp_report_idle_dead().
> >>>Once execution passes the call to rcu_report_dead(), RCU is ignoring
> >>>the CPU, which results in lockdep complaints when the interrupt handler
> >>>uses RCU:
> >>
> >>>diff --git a/kernel/cpu.c b/kernel/cpu.c
> >>>index 448efc06bb2d..3b33d83b793d 100644
> >>>--- a/kernel/cpu.c
> >>>+++ b/kernel/cpu.c
> >>>@@ -930,6 +930,7 @@ void cpuhp_report_idle_dead(void)
> >>> struct cpuhp_cpu_state *st = this_cpu_ptr(&cpuhp_state);
> >>> BUG_ON(st->state != CPUHP_AP_OFFLINE);
> >>>+ local_irq_disable();
> >>> rcu_report_dead(smp_processor_id());
> >>> st->state = CPUHP_AP_IDLE_DEAD;
> >>> udelay(1000);
> >>
> >>Urgh... I'd almost suggest we do something like the below.
> >>
> >>
> >>But then I started looking at the various arch_cpu_idle_dead()
> >>implementations and ran into arm's implementation, which is calling
> >>complete() where generic code already established this isn't possible
> >>(see for example cpuhp_report_idle_dead()).
> >
> >IIRC, that should have been migrated over to cpu_report_death(), as
> >arm64 was in commit:
> >
> > 05981277a4de1ad6 ("arm64: Use common outgoing-CPU-notification code")
> >
> >... but it looks like Paul's patch to do so [1] fell through the cracks;
> >I'm not aware of any reason that shouldn't have been taken.
> >[1] https://lore.kernel.org/lkml/1431467407-1223-8-git-send-email-paulmck@linux.vnet.ibm.com/
> >
> >Paul, do you want to resend that?
>
> Please do. We're carrying this patch out-of-tree for while now in
> our EAS integration to get cpu hotplug tests passing on TC2 (arm).
Huh. It still applies. But I have no means of testing it.
And it looks like the reason I dropped it was that I didn't get any
response from the maintainer. I sent a message to this effect to
linux-arm-kernel@lists.infradead.org and linux@arm.linux.org.uk on May
21, 2015.
So here it is again. ;-)
I have queued this locally. Left to myself, I add the two of you on its
Cc: list and run it through my normal process. But given the history,
I would still want either an ack from the maintainer or, better, for
the maintainer to take the patch.
Or is there a better way for us to proceed on this?
Thanx, Paul
------------------------------------------------------------------------
arm: Use common outgoing-CPU-notification code
This commit removes the open-coded CPU-offline notification with new
common code. In particular, this change avoids calling scheduler code
using RCU from an offline CPU that RCU is ignoring. This is a minimal
change. A more intrusive change might invoke the cpu_check_up_prepare()
and cpu_set_state_online() functions at CPU-online time, which would
allow onlining throw an error if the CPU did not go offline properly.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Russell King <linux@arm.linux.org.uk>
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index ebc53804d57b..8687d619260f 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -267,15 +267,13 @@ int __cpu_disable(void)
return 0;
}
-static DECLARE_COMPLETION(cpu_died);
-
/*
* called on the thread which is asking for a CPU to be shutdown -
* waits until shutdown has completed, or it is timed out.
*/
void __cpu_die(unsigned int cpu)
{
- if (!wait_for_completion_timeout(&cpu_died, msecs_to_jiffies(5000))) {
+ if (!cpu_wait_death(cpu, 5)) {
pr_err("CPU%u: cpu didn't die\n", cpu);
return;
}
@@ -322,7 +320,7 @@ void arch_cpu_idle_dead(void)
* this returns, power and/or clocks can be removed at any point
* from this CPU and its cache by platform_cpu_kill().
*/
- complete(&cpu_died);
+ (void)cpu_report_death();
/*
* Ensure that the cache lines associated with that completion are
next prev parent reply other threads:[~2019-06-04 8:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-02 1:12 [PATCH HACK RFC] cpu: Prevent late-arriving interrupts from disrupting offline Paul E. McKenney
2019-06-03 8:38 ` Peter Zijlstra
2019-06-03 11:44 ` Mark Rutland
2019-06-03 13:39 ` Dietmar Eggemann
2019-06-04 7:45 ` Paul E. McKenney [this message]
2019-06-04 13:29 ` Dietmar Eggemann
2019-06-08 16:41 ` Paul E. McKenney
2019-06-11 13:14 ` Dietmar Eggemann
2019-06-11 13:54 ` Paul E. McKenney
2019-06-11 14:39 ` Dietmar Eggemann
2019-06-11 19:25 ` Paul E. McKenney
2019-06-04 8:14 ` Paul E. McKenney
2019-06-04 12:06 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190604074549.GP28207@linux.ibm.com \
--to=paulmck@linux.ibm.com \
--cc=dietmar.eggemann@arm.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=mojha@codeaurora.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.