2022-09-20 15:49:25

by Yury Norov

[permalink] [raw]
Subject: [PATCH] powerpc/64: don't refer nr_cpu_ids in asm code when it's undefined

generic_secondary_common_init() calls LOAD_REG_ADDR(r7, nr_cpu_ids)
conditionally on CONFIG_SMP. However, if NR_CPUS == 1, kernel doesn't
use the nr_cpu_ids, and in C code, it's just:
#if NR_CPUS == 1
#define nr_cpu_ids
...

The [1] makes declaration of nr_cpu_ids conditional on NR_CPUS == 1,
and that reveals the issue: compiler can't link the
LOAD_REG_ADDR(r7, nr_cpu_ids) against nonexisting symbol.

Current code looks unsafe for those who build kernel with CONFIG_SMP=y and
NR_CPUS == 1. This is weird configuration, but not disallowed.

Fix the linker error by replacing LOAD_REG_ADDR() with LOAD_REG_IMMEDIATE()
conditionally on NR_CPUS == 1.

The issue was spotted after applying [1], which adds a CONFIG_FORCE_NR_CPUS
option that has the similar effect on nr_cpu_ids. So, in this patch, make
the LOAD_REG() conditional on CONFIG_FORCE_NR_CPUS too.

On top of:
[1] https://lore.kernel.org/lkml/[email protected]/T/#m96ffe122721893471fd3470d911a8f2fad6d03b3

Reported-by: Stephen Rothwell <[email protected]>
Signed-off-by: Yury Norov <[email protected]>
---
arch/powerpc/kernel/head_64.S | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index cf2c08902c05..7cb97881635e 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -400,7 +400,11 @@ generic_secondary_common_init:
#else
LOAD_REG_ADDR(r8, paca_ptrs) /* Load paca_ptrs pointe */
ld r8,0(r8) /* Get base vaddr of array */
+#if (NR_CPUS == 1) || defined(CONFIG_FORCE_NR_CPUS)
+ LOAD_REG_IMMEDIATE(r7, NR_CPUS)
+#else
LOAD_REG_ADDR(r7, nr_cpu_ids) /* Load nr_cpu_ids address */
+#endif
lwz r7,0(r7) /* also the max paca allocated */
li r5,0 /* logical cpu id */
1:
--
2.34.1


2022-09-20 22:31:13

by Stephen Rothwell

[permalink] [raw]
Subject: Re: [PATCH] powerpc/64: don't refer nr_cpu_ids in asm code when it's undefined

Hi Yury,

On Tue, 20 Sep 2022 08:29:35 -0700 Yury Norov <[email protected]> wrote:
>

> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> index cf2c08902c05..7cb97881635e 100644
> --- a/arch/powerpc/kernel/head_64.S
> +++ b/arch/powerpc/kernel/head_64.S
> @@ -400,7 +400,11 @@ generic_secondary_common_init:
> #else
> LOAD_REG_ADDR(r8, paca_ptrs) /* Load paca_ptrs pointe */
> ld r8,0(r8) /* Get base vaddr of array */
> +#if (NR_CPUS == 1) || defined(CONFIG_FORCE_NR_CPUS)
> + LOAD_REG_IMMEDIATE(r7, NR_CPUS)
> +#else
> LOAD_REG_ADDR(r7, nr_cpu_ids) /* Load nr_cpu_ids address */
> +#endif
> lwz r7,0(r7) /* also the max paca allocated */
> li r5,0 /* logical cpu id */
> 1:
> --
> 2.34.1
>

I don't know PPC assembly very well, but should the #endif be one line
lower so that the constant is not dereferenced in the non-#else case?

--
Cheers,
Stephen Rothwell


Attachments:
(No filename) (499.00 B)
OpenPGP digital signature

2022-09-20 22:52:51

by Yury Norov

[permalink] [raw]
Subject: Re: [PATCH] powerpc/64: don't refer nr_cpu_ids in asm code when it's undefined

On Wed, Sep 21, 2022 at 08:20:06AM +1000, Stephen Rothwell wrote:
> Hi Yury,
>
> On Tue, 20 Sep 2022 08:29:35 -0700 Yury Norov <[email protected]> wrote:
> >
>
> > diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> > index cf2c08902c05..7cb97881635e 100644
> > --- a/arch/powerpc/kernel/head_64.S
> > +++ b/arch/powerpc/kernel/head_64.S
> > @@ -400,7 +400,11 @@ generic_secondary_common_init:
> > #else
> > LOAD_REG_ADDR(r8, paca_ptrs) /* Load paca_ptrs pointe */
> > ld r8,0(r8) /* Get base vaddr of array */
> > +#if (NR_CPUS == 1) || defined(CONFIG_FORCE_NR_CPUS)
> > + LOAD_REG_IMMEDIATE(r7, NR_CPUS)
> > +#else
> > LOAD_REG_ADDR(r7, nr_cpu_ids) /* Load nr_cpu_ids address */
> > +#endif
> > lwz r7,0(r7) /* also the max paca allocated */
> > li r5,0 /* logical cpu id */
> > 1:
> > --
> > 2.34.1
> >
>
> I don't know PPC assembly very well, but should the #endif be one line
> lower so that the constant is not dereferenced in the non-#else case?

Looks like you're right. Thanks, I'll send a v2.