linux-kernel - Re: [PATCH v2 1/1] hung_task: fix warnings caused by unaligned lock pointers

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: <gtie7ylcuftmi2jgzviipxnvjzcds46eqce4fxxalbutwphbe4@erwrj3p7udrz>
Date: Tue, 9 Sep 2025 21:48:06 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Finn Thain <fthain@...ux-m68k.org>
Cc: Lance Yang <lance.yang@...ux.dev>, akpm@...ux-foundation.org, 
	amaindex@...look.com, anna.schumaker@...cle.com, boqun.feng@...il.com, 
	geert@...ux-m68k.org, ioworker0@...il.com, joel.granados@...nel.org, 
	jstultz@...gle.com, leonylgao@...cent.com, linux-kernel@...r.kernel.org, 
	linux-m68k@...ts.linux-m68k.org, longman@...hat.com, mhiramat@...nel.org, mingo@...hat.com, 
	mingzhe.yang@...com, oak@...sinkinet.fi, peterz@...radead.org, rostedt@...dmis.org, 
	senozhatsky@...omium.org, tfiga@...omium.org, will@...nel.org, stable@...r.kernel.org
Subject: Re: [PATCH v2 1/1] hung_task: fix warnings caused by unaligned lock
 pointers

On Wed, Sep 10, 2025 at 11:35:56AM +1000, Finn Thain wrote:
> Similarly, on m68k, there is no issue with __alignof(long) == 2 because 
> these platforms don't trap on misaligned access. But that seems a bit 
> irrelevant to the real issue, which is not specific architectural quirks, 
> but the algorithms and their ongoing development.

Err, I believe the topic was just alignment and the breaking of commonly
held expectations :)

> 
> > ...
> > > 
> > > IMHO, good C doesn't make alignment assumptions, because that hinders 
> > > source code portability and reuse, as well as algorithm extensibility. 
> > > We've seen it before. The issue here [1] is no different from the 
> > > pointer abuse which we fixed in Cpython [2].
> > 
> > That kind of thinking really dates from before multithreaded and even 
> > lockless algorithms became absolutely pervasive, especially in the 
> > kernel.
> > 
> 
> What I meant was, "assumptions hinder portability etc." not "good C 
> hinders portability etc." (my bad).

Of course, but given the lack of a true atomic type in C there's no good
alternative way to avoid this landmine.

Also, grep for READ_ONCE/WRITE_ONCE in the kernel tree if you want to
see how big the issue is - ad then remember that only captures a
fraction of it :)

> 
> > These days, READ_ONCE() and WRITE_ONCE() are pervasive, and since C 
> > lacks any notion of atomics in the type system (the place this primarily 
> > comes up), it would go a long ways towards improving portability and 
> > eliminating nasty land mines.
> > 
> 
> Natural alignment would seem to be desirable for new ABIs, until you 
> realize that it implies wasted RAM on embedded systems and reduced data 
> locality (that is, cooler caches if you did this on i386).

For the data structures where it matters we tend to organize things by
natural alignment already.

If anyone wanted to gather precise numbers, there's memory allocation
profiling + pahole :)