All of lore.kernel.org
 help / color / mirror / Atom feed
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC/PATCH] ARM: smp: Fix cpu_up() racing with sys_reboot
Date: Thu, 30 Aug 2012 12:00:06 -0700	[thread overview]
Message-ID: <503FB836.2060000@codeaurora.org> (raw)
In-Reply-To: <20120829235353.GW18957@n2100.arm.linux.org.uk>

On 8/29/2012 4:53 PM, Russell King - ARM Linux wrote:
> On Tue, Aug 21, 2012 at 09:03:49PM -0700, Stephen Boyd wrote:
>> Nothing stops a process from hotplugging in a CPU concurrently
>> with a sys_reboot() call. In such a situation we could have
>> ipi_cpu_stop() mark a cpu as 'offline' and _cpu_up() ignore the
>> fact that the CPU is not really offline and call the
>> CPU_UP_PREPARE notifier. When this happens stop_machine code will
>> complain that the cpu thread already exists and BUG_ON().
> This puts us at odds with x86, which is a bad thing without first
> investigating whether a generic solution which fixes all arches would
> be more appropriate.

I went this way because it seems that we stop CPUs in architecture
specific code instead of doing it generically (although we have
smp_send_stop()?). It would be nice if we could generalize the cpu
stopping code so that reboot at the architectual level doesn't have to
do this.

>
> A better solution may be to mark those CPUs as being not-present,
> which will prevent them being hot-plugged back.

That sounds fine to me. I can s/active/present/ for v2 if we can get
some kind of consensus. I was also thinking we could stop using these
functions entirely and have some private stopped CPUs map that we check
instead.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@codeaurora.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC/PATCH] ARM: smp: Fix cpu_up() racing with sys_reboot
Date: Thu, 30 Aug 2012 12:00:06 -0700	[thread overview]
Message-ID: <503FB836.2060000@codeaurora.org> (raw)
In-Reply-To: <20120829235353.GW18957@n2100.arm.linux.org.uk>

On 8/29/2012 4:53 PM, Russell King - ARM Linux wrote:
> On Tue, Aug 21, 2012 at 09:03:49PM -0700, Stephen Boyd wrote:
>> Nothing stops a process from hotplugging in a CPU concurrently
>> with a sys_reboot() call. In such a situation we could have
>> ipi_cpu_stop() mark a cpu as 'offline' and _cpu_up() ignore the
>> fact that the CPU is not really offline and call the
>> CPU_UP_PREPARE notifier. When this happens stop_machine code will
>> complain that the cpu thread already exists and BUG_ON().
> This puts us at odds with x86, which is a bad thing without first
> investigating whether a generic solution which fixes all arches would
> be more appropriate.

I went this way because it seems that we stop CPUs in architecture
specific code instead of doing it generically (although we have
smp_send_stop()?). It would be nice if we could generalize the cpu
stopping code so that reboot at the architectual level doesn't have to
do this.

>
> A better solution may be to mark those CPUs as being not-present,
> which will prevent them being hot-plugged back.

That sounds fine to me. I can s/active/present/ for v2 if we can get
some kind of consensus. I was also thinking we could stop using these
functions entirely and have some private stopped CPUs map that we check
instead.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.


  reply	other threads:[~2012-08-30 19:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-22  4:03 [RFC/PATCH] ARM: smp: Fix cpu_up() racing with sys_reboot Stephen Boyd
2012-08-22  4:03 ` Stephen Boyd
2012-08-29  7:24 ` Stephen Boyd
2012-08-29  7:24   ` Stephen Boyd
2012-08-29 23:53 ` Russell King - ARM Linux
2012-08-29 23:53   ` Russell King - ARM Linux
2012-08-30 19:00   ` Stephen Boyd [this message]
2012-08-30 19:00     ` Stephen Boyd

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=503FB836.2060000@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.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 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.