Re: [PATCH] ppc64 boot: Wait for boot cpu to show up if nr_cpus limit is about to hit.

[Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com>]

On 02/02/2016 07:28 PM, Denis Kirjanov wrote:
> On 2/1/16, Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> wrote:
>> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>>
>> The kernel boot parameter 'nr_cpus=' allows one to specify number of
>> possible cpus in the system. In the normal scenario the first cpu (cpu0)
>> that shows up is the boot cpu and hence it gets covered under nr_cpus
>> limit.
>>
>> But this assumption will be broken in kdump scenario where kdump kenrel
>> after a crash can boot up on an non-zero boot cpu. The paca structure
>> allocation depends on value of nr_cpus and is indexed using logical cpu
>> ids. This definetly will be an issue if boot cpu id > nr_cpus
> And what happend in this case? Have you tried it out?

Yes I have. It results into memory corruption when
set_hard_smp_processor_id(boot_cpu_id,..) is called from
early_init_dt_scan_cpus() and then kernel fails to boot. Nothing shows
up in console and system hangs forever.

You can easily reproduce this by configuring kdump service to use
'nr_cpus=1' instead of 'maxcpus=1' and then trigger system crash from
any cpu other than 0

e.g.  $ taskset -c 10 echo c > /proc/sysrq-trigger

Thanks,
-Mahesh.