From: Suzuki.Poulose@arm.com (Suzuki K. Poulose)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 4/7] arm64: Handle early CPU boot failures
Date: Wed, 3 Feb 2016 17:24:07 +0000 [thread overview]
Message-ID: <56B237B7.1060805@arm.com> (raw)
In-Reply-To: <20160203170114.GD1234@leverpostej>
On 03/02/16 17:01, Mark Rutland wrote:
> On Mon, Jan 25, 2016 at 06:07:02PM +0000, Suzuki K Poulose wrote:
>> From: Suzuki K. Poulose <suzuki.poulose@arm.com>
>>
>> 3. CPU_PANIC_KERNEL - CPU detected some serious issues which
>> requires kernel to crash immediately. The secondary CPU cannot
>> call panic() until it has initialised the GIC. This flag can
>> be used to instruct the master to do so.
>
> When would we use this last case?
As of now, it is used when we have incompatible ASID bits.
>
> Perhaps a better option is to always throw any incompatible CPU into an
> (MMU-off) pen, and assume that it's stuck in the kernel, even if we
> could theoretically turn it off.
Right, that is another option. I am fine with either.
>> - b __no_granule_support
>> + wfi
>> + b 1b
>
> The addition of wfi seems fine, but should be mentioned in the commit
> message.
Sure.
>> struct secondary_data secondary_data;
>> +/* Number of CPUs which aren't online, but looping in kernel text. */
>> +u32 cpus_stuck_in_kernel;
>
> Why u32 rather than int?
No specific reasons, since it is going to be a quantity, which cannot be < 0,
kept it unsigned. It could be unsigned int.
>> +#ifdef CONFIG_HOTPLUG_CPU
>> +static int op_cpu_kill(unsigned int cpu);
>> +#else
>> +static inline int op_cpu_kill(unsigned int cpu)
>> +{
>> + return -ENOSYS;
>> +}
>> +#endif
>
> There is no !CONFIG_HOTPLUG_CPU configuration any more.
Thats what I thought but then there was [1]. If you disable CONFIG_PM_SLEEP, you can
still build with !CONFIG_HOTPLUG_CPU (or in other words allnoconfig)
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/384589.html
>>
>> + /* Make sure the update to status is visible */
>> + smp_rmb();
>> secondary_data.stack = NULL;
>> + status = READ_ONCE(secondary_data.status);
>
> What is the rmb intended to order here?
It was for the complete(). But...
>> + update_cpu_boot_status(CPU_BOOT_SUCCESS);
>> + /* Make sure the status update is visible before we complete */
>> + smp_wmb();
>
> Surely complete() has appropriate barriers?
Yes, it does. We can remove it.
>> #ifdef CONFIG_HOTPLUG_CPU
>> + update_cpu_boot_status(CPU_KILL_ME);
>> /* Check if we can park ourselves */
>> if (cpu_ops[cpu] && cpu_ops[cpu]->cpu_die)
>> cpu_ops[cpu]->cpu_die(cpu);
>
> I think you need a barrier to ensure visibility of the store prior to
> calling cpu_die (i.e. you want to order an access against execution). A
> dsb is what you want -- smp_wmb() only expands to a dmb.
>
OK.
>> #endif
>> + update_cpu_boot_status(CPU_STUCK_IN_KERNEL);
>>
>> cpu_park_loop();
>
> Likewise here.
OK.
Thanks
Suzuki
next prev parent reply other threads:[~2016-02-03 17:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-25 18:06 [PATCH v4 0/7] arm64: Verify early CPU features Suzuki K Poulose
2016-01-25 18:06 ` [PATCH v4 1/7] arm64: Add a helper for parking CPUs in a loop Suzuki K Poulose
2016-01-25 18:07 ` [PATCH v4 2/7] arm64: Introduce cpu_die_early Suzuki K Poulose
2016-01-25 18:07 ` [PATCH v4 3/7] arm64: Move cpu_die_early to smp.c Suzuki K Poulose
2016-01-25 18:07 ` [PATCH v4 4/7] arm64: Handle early CPU boot failures Suzuki K Poulose
2016-02-03 12:57 ` Catalin Marinas
2016-02-03 16:46 ` Mark Rutland
2016-02-03 17:34 ` Catalin Marinas
2016-02-03 17:53 ` Mark Rutland
2016-02-03 18:12 ` Catalin Marinas
2016-02-03 19:31 ` Mark Rutland
2016-02-03 17:23 ` Suzuki K. Poulose
2016-02-03 17:01 ` Mark Rutland
2016-02-03 17:15 ` Catalin Marinas
2016-02-03 17:24 ` Suzuki K. Poulose [this message]
2016-02-03 17:35 ` Mark Rutland
2016-01-25 18:07 ` [PATCH v4 5/7] arm64: Enable CPU capability verification unconditionally Suzuki K Poulose
2016-01-25 18:07 ` [PATCH v4 6/7] arm64: Add helper for extracting ASIDBits Suzuki K Poulose
2016-01-25 18:07 ` [PATCH v4 7/7] arm64: Ensure the secondary CPUs have safe ASIDBits size Suzuki K Poulose
2016-02-09 17:20 ` [PATCH v4 0/7] arm64: Verify early CPU features Will Deacon
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=56B237B7.1060805@arm.com \
--to=suzuki.poulose@arm.com \
--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.