From: Peter Zijlstra <peterz@infradead.org>
To: Don Zickus <dzickus@redhat.com>
Cc: x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
tony.luck@intel.com, seiji.aguchi@hds.com, ak@linux.intel.com,
mjg@redhat.com, levinsasha928@gmail.com
Subject: Re: [PATCH 2/2] x86, reschedule: check to see if system is shutting down
Date: Wed, 15 Feb 2012 12:26:37 +0100 [thread overview]
Message-ID: <1329305197.2293.50.camel@twins> (raw)
In-Reply-To: <1329164860-668-3-git-send-email-dzickus@redhat.com>
On Mon, 2012-02-13 at 15:27 -0500, Don Zickus wrote:
> Due to reschedule changes in v3.3, a WARN_ON has popped up
> because a cpu suddenly became offline without letting anyone
> know.
>
> This results in the schedule trying to move something to another
> cpu only to find out it isn't there and getting confused. The splat
> looks something like:
<snip>
> I solved this by re-using the atomic global variable that is set during
> native_smp_stop_other_cpus(). This is the piece of code that causes the
> problem and it sets stopping_cpu to reflect the system is going down.
>
> If the variable is set do not yell with the WARN_ON, just return.
>
> v2: use if-condition for WARN-ON instead of if {WARN_ON(1)}
>
> Signed-off-by: Don Zickus <dzickus@redhat.com>
> ---
> arch/x86/kernel/smp.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
> index 48d2b7d..54d570e 100644
> --- a/arch/x86/kernel/smp.c
> +++ b/arch/x86/kernel/smp.c
> @@ -120,7 +120,8 @@ static bool smp_no_nmi_ipi = false;
> static void native_smp_send_reschedule(int cpu)
> {
> if (unlikely(cpu_is_offline(cpu))) {
> - WARN_ON(1);
> + /* system is not shutting down.. yell */
> + WARN_ON(atomic_read(&stopping_cpu) == -1)
> return;
> }
> apic->send_IPI_mask(cpumask_of(cpu), RESCHEDULE_VECTOR);
Right, so this fixes this one particular case, I imagine there's tons of
places that could go splat due to this (but don't quite yet for some
reason).
We can't go around annotating everything, nor would we want to simply
shut up all warnings for fear of missing an actual error.
Why can't the normal shut-down path use a less crazy approach to going
down?
next prev parent reply other threads:[~2012-02-15 11:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-13 20:27 [PATCH 0/2 v2] x86, reboot: cleanup NMI and REBOOT_IRQ Don Zickus
2012-02-13 20:27 ` [PATCH 1/2] x86, reboot: revert stop_other_cpus to using IRQ with NMI fallback Don Zickus
2012-03-02 20:41 ` Seiji Aguchi
2012-03-02 21:11 ` Don Zickus
2012-03-02 21:55 ` Seiji Aguchi
2012-02-13 20:27 ` [PATCH 2/2] x86, reschedule: check to see if system is shutting down Don Zickus
2012-02-13 21:22 ` Seiji Aguchi
2012-02-13 22:43 ` Don Zickus
2012-02-15 11:26 ` Peter Zijlstra [this message]
2012-02-15 14:54 ` Don Zickus
2012-02-15 14:57 ` Peter Zijlstra
2012-02-15 15:57 ` Don Zickus
2012-02-15 17:59 ` Peter Zijlstra
2012-02-16 3:14 ` Don Zickus
-- strict thread matches above, loose matches on Subject: below --
2012-02-10 21:02 [PATCH 0/2] x86, reboot: cleanup NMI and REBOOT_IRQ Don Zickus
2012-02-10 21:02 ` [PATCH 2/2] x86, reschedule: check to see if system is shutting down Don Zickus
2012-02-10 22:42 ` Luck, Tony
2012-02-10 22:53 ` Don Zickus
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=1329305197.2293.50.camel@twins \
--to=peterz@infradead.org \
--cc=ak@linux.intel.com \
--cc=dzickus@redhat.com \
--cc=levinsasha928@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg@redhat.com \
--cc=seiji.aguchi@hds.com \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox