Re: [PATCH] atomic: Specify natural alignment for atomic_t

[Lance Yang]

On 2025/8/25 20:07, David Laight wrote:
> On Mon, 25 Aug 2025 15:46:42 +0800
> Lance Yang <lance.yang@xxxxxxxxx> wrote:
>
> > On 2025/8/25 14:17, Finn Thain wrote:
> > > On Mon, 25 Aug 2025, Lance Yang wrote:
> > >    
> > > > What if we squash the runtime check fix into your patch?
> > >
> > > Did my patch not solve the problem?
> >
> > Hmm... it should solve the problem for natural alignment, which is a
> > critical fix.
> >
> > But it cannot solve the problem of forced misalignment from drivers using
> > #pragma pack(1). The runtime warning will still trigger in those cases.
> >
> > I built a simple test module on a kernel with your patch applied:
> >
> > ```
> > #include <linux/module.h>
> > #include <linux/init.h>
> >
> > struct __attribute__((packed)) test_container {
> >       char padding[49];
> >       struct mutex io_lock;
> > };
> >
> > static int __init alignment_init(void)
> > {
> >       struct test_container cont;
> >       pr_info("io_lock address offset mod 4: %lu\n", (unsigned long)&cont.io_lock % 4);
>
> Doesn't that give a compilation warning from 'taking the address of a packed member'?
> Ignore that at your peril.

Hmm, I don't see that acctully ...

> More problematic is that, IIRC, m68k kmalloc() allocates 16bit aligned memory.
> This has broken other things in the past.
> I doubt that increasing the alignment to 32bits would make much difference
> to the kernel memory footprint.

@Finn Given this new information, how about we just apply the runtime check
fix for now?

Since we plan to remove the entire pointer-encoding scheme later anyway, a
minimal and targeted change could be the logical choice. It's easy and safe
to backport, and it cleanly stops the warnings from all sources without
introducing new risks - exactly what we need for stable kernels.

Cheers,
Lance