[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1329305197.2293.50.camel@twins>
Date: Wed, 15 Feb 2012 12:26:37 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Don Zickus <dzickus@...hat.com>
Cc: x86@...nel.org, LKML <linux-kernel@...r.kernel.org>,
tony.luck@...el.com, seiji.aguchi@....com, ak@...ux.intel.com,
mjg@...hat.com, levinsasha928@...il.com
Subject: Re: [PATCH 2/2] x86, reschedule: check to see if system is shutting
down
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@...hat.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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists