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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).