linux-kernel - Re: [PATCH] atomic: Specify natural alignment for atomic

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: <c7e8123c-7acb-4444-ae0d-83cdee0bfb85@linux.dev>
Date: Wed, 27 Aug 2025 17:34:25 +0800
From: Lance Yang <lance.yang@...ux.dev>
To: Finn Thain <fthain@...ux-m68k.org>
Cc: David Laight <david.laight.linux@...il.com>, akpm@...ux-foundation.org,
 geert@...ux-m68k.org, linux-kernel@...r.kernel.org, mhiramat@...nel.org,
 oak@...sinkinet.fi, peterz@...radead.org, stable@...r.kernel.org,
 will@...nel.org, Lance Yang <ioworker0@...il.com>
Subject: Re: [PATCH] atomic: Specify natural alignment for atomic_t



On 2025/8/27 16:00, Finn Thain wrote:
> 
> On Mon, 25 Aug 2025, Lance Yang wrote:
> 
>>>
>>> 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?
> 
> New information? No, that's just hear-say.

Emm... I jumped the gun there ;p

> 
>> 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.
>>
> 
> Well, that's up to you, of course. If you want my comment, I'd only ask
> whether or not the bug is theoretical (outside of m68k).

Well, let's apply both this fix and the runtime check fix[1] as Masami
suggested ;)

[1] https://lore.kernel.org/lkml/20250823050036.7748-1-lance.yang@linux.dev/