linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  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).