Re: [PATCH V2] LoongArch: Align ACPI structures if ARCH_STRICT_ALIGN enabled

[Guenter Roeck <linux@roeck-us.net>]

On Sun, Sep 21, 2025 at 09:07:38AM +0800, Huacai Chen wrote:
> Hi, Nathan,
> 
> On Sun, Sep 21, 2025 at 7:48 AM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > Hi Huacai,
> >
> > On Wed, Sep 10, 2025 at 05:10:33PM +0800, Huacai Chen wrote:
> > > ARCH_STRICT_ALIGN is used for hardware without UAL, now it only control
> > > the -mstrict-align flag. However, ACPI structures are packed by default
> > > so will cause unaligned accesses.
> > >
> > > To avoid this, define ACPI_MISALIGNMENT_NOT_SUPPORTED in asm/acenv.h to
> > > align ACPI structures if ARCH_STRICT_ALIGN enabled.
> > >
> > > Cc: stable@vger.kernel.org
> > > Reported-by: Binbin Zhou <zhoubinbin@loongson.cn>
> > > Suggested-by: Xi Ruoyao <xry111@xry111.site>
> > > Suggested-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > ---
> > > V2: Modify asm/acenv.h instead of Makefile.
> > >
> > >  arch/loongarch/include/asm/acenv.h | 7 +++----
> > >  1 file changed, 3 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/loongarch/include/asm/acenv.h b/arch/loongarch/include/asm/acenv.h
> > > index 52f298f7293b..483c955f2ae5 100644
> > > --- a/arch/loongarch/include/asm/acenv.h
> > > +++ b/arch/loongarch/include/asm/acenv.h
> > > @@ -10,9 +10,8 @@
> > >  #ifndef _ASM_LOONGARCH_ACENV_H
> > >  #define _ASM_LOONGARCH_ACENV_H
> > >
> > > -/*
> > > - * This header is required by ACPI core, but we have nothing to fill in
> > > - * right now. Will be updated later when needed.
> > > - */
> > > +#ifdef CONFIG_ARCH_STRICT_ALIGN
> > > +#define ACPI_MISALIGNMENT_NOT_SUPPORTED
> > > +#endif /* CONFIG_ARCH_STRICT_ALIGN */
> > >
> > >  #endif /* _ASM_LOONGARCH_ACENV_H */
> >
> > I am seeing several ACPI errors in my QEMU testing after this change in
> > Linus's tree as commit a9d13433fe17 ("LoongArch: Align ACPI structures
> > if ARCH_STRICT_ALIGN enabled").
> >
> >   $ make -skj"$(nproc)" ARCH=loongarch CROSS_COMPILE=loongarch64-linux- clean defconfig vmlinuz.efi
> >   kernel/sched/fair.o: warning: objtool: sched_update_scaling() falls through to next function init_entity_runnable_average()
> >   mm/mempolicy.o: warning: objtool: alloc_pages_bulk_mempolicy_noprof+0x380: stack state mismatch: reg1[30]=-1+0 reg2[30]=-2-80
> >   lib/crypto/mpi/mpih-div.o: warning: objtool: mpihelp_divrem+0x2d0: stack state mismatch: reg1[22]=-1+0 reg2[22]=-2-16
> >   In file included from include/acpi/acpi.h:24,
> >                    from drivers/acpi/acpica/tbprint.c:10:
> >   drivers/acpi/acpica/tbprint.c: In function 'acpi_tb_print_table_header':
> >   include/acpi/actypes.h:530:43: warning: 'strncmp' argument 1 declared attribute 'nonstring' is smaller than the specified bound 8 [-Wstringop-overread]
> >     530 | #define ACPI_VALIDATE_RSDP_SIG(a)       (!strncmp (ACPI_CAST_PTR (char, (a)), ACPI_SIG_RSDP, (sizeof(a) < 8) ? ACPI_NAMESEG_SIZE : 8))
> >         |                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >   drivers/acpi/acpica/tbprint.c:105:20: note: in expansion of macro 'ACPI_VALIDATE_RSDP_SIG'
> >     105 |         } else if (ACPI_VALIDATE_RSDP_SIG(ACPI_CAST_PTR(struct acpi_table_rsdp,
> >         |                    ^~~~~~~~~~~~~~~~~~~~~~
> >   In file included from include/acpi/acpi.h:26:
> >   include/acpi/actbl.h:69:14: note: argument 'signature' declared here
> >      69 |         char signature[ACPI_NAMESEG_SIZE] ACPI_NONSTRING;       /* ASCII table signature */
> >         |              ^~~~~~~~~
> >From this link this seems a comiler issue (at least not an
> arch-specific kernel issue):
> https://github.com/AOSC-Tracking/linux/commit/1e9ee413357ef58dd902f6ec55013d2a2f2043eb
> 

I see that the patch made it into the upstream kernel, now breaking both
mainline and 6.16.y test builds of loongarch64:allmodconfig with gcc.

Since this is apparently intentional, I'll stop build testing
loongarch64:allmodconfig. So far it looks like my qemu tests
are not affected, so I'll continue testing those for the time being.

Guenter