linux-kernel - Re: [RFC v2 2/3] atomic: Specify alignment for atomic_t and atomic64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c130a0bd-f581-a1da-cc10-0c09c782dfca@linux-m68k.org>
Date: Mon, 15 Sep 2025 19:26:46 +1000 (AEST)
From: Finn Thain <fthain@...ux-m68k.org>
To: Arnd Bergmann <arnd@...db.de>
cc: Peter Zijlstra <peterz@...radead.org>, Will Deacon <will@...nel.org>, 
    Andrew Morton <akpm@...ux-foundation.org>, 
    Boqun Feng <boqun.feng@...il.com>, Jonathan Corbet <corbet@....net>, 
    Mark Rutland <mark.rutland@....com>, linux-kernel@...r.kernel.org, 
    Linux-Arch <linux-arch@...r.kernel.org>, 
    Geert Uytterhoeven <geert@...ux-m68k.org>, linux-m68k@...r.kernel.org, 
    Lance Yang <lance.yang@...ux.dev>
Subject: Re: [RFC v2 2/3] atomic: Specify alignment for atomic_t and
 atomic64_t


On Mon, 15 Sep 2025, Arnd Bergmann wrote:

> On Sun, Sep 14, 2025, at 02:45, Finn Thain wrote:
> > index 100d24b02e52..7ae82ac17645 100644
> > --- a/include/asm-generic/atomic64.h
> > +++ b/include/asm-generic/atomic64.h
> > @@ -10,7 +10,7 @@
> >  #include <linux/types.h>
> > 
> >  typedef struct {
> > -	s64 counter;
> > +	s64 counter __aligned(sizeof(long));
> >  } atomic64_t;
> 
> Why is this not aligned to 8 bytes? I checked all supported 
> architectures and found that arc, csky, m68k, microblaze, openrisc, sh 
> and x86-32 use a smaller alignment by default, but arc and x86-32 
> override it to 8 bytes already. x86 changed it back in 2009 with commit 
> bbf2a330d92c ("x86: atomic64: The atomic64_t data type should be 8 bytes 
> aligned on 32-bit too"), and arc uses the same one.
> 

Right, I forgot to check includes in arch/x86/include. (I had assumed this 
definition was relevant to that architecture, hence the sizeof(long), in 
order to stick to native alignment on x86-32.)

> Changing csky, m68k, microblaze, openrisc and sh to use the same 
> alignment as all others is probably less risky in the long run in case 
> anything relies on that the same way that code expects native alignment 
> on atomic_t.
> 

By "native alignment", do you mean "natural alignment" here?