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: <20250827115447.GR3289052@noisy.programming.kicks-ass.net>
Date: Wed, 27 Aug 2025 13:54:47 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Finn Thain <fthain@...ux-m68k.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Lance Yang <lance.yang@...ux.dev>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Eero Tamminen <oak@...sinkinet.fi>, Will Deacon <will@...nel.org>,
	stable@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] atomic: Specify natural alignment for atomic_t

On Wed, Aug 27, 2025 at 05:17:19PM +1000, Finn Thain wrote:
> 
> On Mon, 25 Aug 2025, Peter Zijlstra wrote:
> 
> > On Mon, Aug 25, 2025 at 06:03:23PM +1000, Finn Thain wrote:
> > > 
> > > On Mon, 25 Aug 2025, Peter Zijlstra wrote:
> > > 
> > > > 
> > > > And your architecture doesn't trap on unaligned atomic access ?!!?!
> > > > 
> > > 
> > > Right. This port doesn't do SMP.
> > 
> > There is RMW_INSN which seems to imply a compare-and-swap instruction of 
> > sorts. That is happy to work on unaligned storage?
> > 
> 
> Yes, the TAS and CAS instructions are happy to work on unaligned storage. 
> 
> However, these operations involve an indivisible bus cycle that hogs the 
> bus to the detriment of other processors, DMA controllers etc. So I 
> suspect lock alignment would tend to shorten read-modify-write cycles, and 
> improve efficiency, when CONFIG_RMW_INSN is enabled.
> 
> Most m68k platforms will have CONFIG_RMW_INSN disabled, or else simply 
> don't implement TAS and CAS. In this case, lock alignment might still 
> help, just because L1 cache entries are long words. I've not tried to 
> measure this.

Fair enough; this sounds a little like the x86 LOCK prefix, it will work
on unaligned memory, but at tremendous cost (recent chips have an
optional exception on unaligned).

Anyway, I'm not opposed to adding an explicit alignment to atomic_t.
Isn't s32 or __s32 already having this?

But I think it might make sense to have a DEBUG alignment check right
along with adding that alignment, just to make sure things are indeed /
stay aligned.