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: <fb06c629-6a57-4d14-a5db-b7790b84ce13@app.fastmail.com>
Date: Mon, 15 Sep 2025 11:29:14 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Finn Thain" <fthain@...ux-m68k.org>
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, Sep 15, 2025, at 11:26, Finn Thain wrote:
> On Mon, 15 Sep 2025, Arnd Bergmann wrote:
>> 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.)

Ok

>> 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?

Yes, that's what I meant.

    Arnd