* Gautham R Shenoy [2021-08-23 11:41:22]:
> On Sat, Aug 21, 2021 at 02:54:17PM +0530, Srikar Dronamraju wrote:
> > Aneesh reported a crash with a fairly recent upstream kernel when
> > booting kernel whose commandline was appended with nr_cpus=2
> >
> > 1:mon> e
> > cpu 0x1: Vector: 300 (Data Access) at [c8a67bd0]
> > pc: c002557c: cpu_to_chip_id+0x3c/0x100
> > lr: c0058380: start_secondary+0x460/0xb00
> > sp: c8a67e70
> >msr: 80001033
> >dar: 10
> > dsisr: 8
> > current = 0xc891bb00
> > paca= 0xc018ff981f80 irqmask: 0x03 irq_happened: 0x01
> > pid = 0, comm = swapper/1
> > Linux version 5.13.0-rc3-15704-ga050a6d2b7e8 (kvaneesh@ltc-boston8) (gcc
> > (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu)
> > 2.34) #433 SMP Tue May 25 02:38:49 CDT 2021
> > 1:mon> t
> > [link register ] c0058380 start_secondary+0x460/0xb00
> > [c8a67e70] c8a67eb0 (unreliable)
> > [c8a67eb0] c00589d4 start_secondary+0xab4/0xb00
> > [c8a67f90] c000c654 start_secondary_prolog+0x10/0x14
> >
> > Current code assumes that num_possible_cpus() is always greater than
> > threads_per_core. However this may not be true when using nr_cpus=2 or
> > similar options. Handle the case where num_possible_cpus is smaller than
> > threads_per_core.
> >
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Cc: Aneesh Kumar K.V
> > Cc: Nathan Lynch
> > Cc: Michael Ellerman
> > Cc: Ingo Molnar
> > Cc: Peter Zijlstra
> > Cc: Valentin Schneider
> > Cc: Gautham R Shenoy
> > Cc: Vincent Guittot
> > Fixes: c1e53367dab1 ("powerpc/smp: Cache CPU to chip lookup")
> > Reported-by: Aneesh Kumar K.V
> > Debugged-by: Michael Ellerman
> > Signed-off-by: Srikar Dronamraju
> > ---
> > arch/powerpc/kernel/smp.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> > index 6c6e4d934d86..3d6874fe1937 100644
> > --- a/arch/powerpc/kernel/smp.c
> > +++ b/arch/powerpc/kernel/smp.c
> > @@ -1074,7 +1074,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
> > }
> >
> > if (cpu_to_chip_id(boot_cpuid) != -1) {
> > - int idx = num_possible_cpus() / threads_per_core;
> > + int idx = max((int)num_possible_cpus() / threads_per_core, 1);
>
> I think this code was assuming that num_possible_cpus() is a multiple
> of threads_per_core.
>
> So, on a system with threads_per_core=8, if we pass nr_cpus=10, we
> will still get idx=1. Thus, we will allocate only one entry in
> chip_id_lookup_table[] even though there are two cores and
> chip_id_lookup_table[] is expected to have one entry per core.
>
> Is this a valid scenario ? If yes, should we use
>
>idx = DIV_ROUND_UP(num_possible_cpus, threads_per_core);
>
Yes, this can be done.
will resend this patch with this change.
>
> >
> > /*
> > * All threads of a core will all belong to the same core,
> > --
> > 2.18.2
> >
>
> --
> Thanks and Regards
> gautham.
--
Thanks and Regards
Srikar Dronamraju
