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: <ufkr7rkg7rsfo6ovsnwz2gqf4mtmmevb3mququeukqlryzwzmz@x4chw22ojvnu>
Date: Tue, 9 Sep 2025 20:51:41 -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 10:07:04AM +1000, Finn Thain wrote:
> 
> On Tue, 9 Sep 2025, Kent Overstreet wrote:
> 
> > On Tue, Sep 09, 2025 at 10:52:43PM +0800, Lance Yang wrote:
> > > From: Lance Yang <lance.yang@...ux.dev>
> > > 
> > > The blocker tracking mechanism assumes that lock pointers are at least
> > > 4-byte aligned to use their lower bits for type encoding.
> > > 
> > > However, as reported by Eero Tamminen, some architectures like m68k
> > > only guarantee 2-byte alignment of 32-bit values. This breaks the
> > > assumption and causes two related WARN_ON_ONCE checks to trigger.
> > 
> > Isn't m68k the only architecture that's weird like this?
> > 
> 
> No. Historically, Linux/CRIS did not naturally align integer types either. 
> AFAIK, there's no standard that demands natural alignment of integer 
> types. Linux ABIs differ significantly.
> 
> For example, Linux/i386 does not naturally align long longs. Therefore, 
> x86 may be expected to become the next m68k (or CRIS) unless such 
> assumptions are avoided and alignment requirements are made explicit.

That doesn't really apply; i386's long long is ugly but it's not as much
of an issue in practice, because it's greater than a machine word.

> The real problem here is the algorithm. Some under-resourced distros 
> choose to blame the ABI instead of the algorithm, because in doing so, 
> they are freed from having to work to improve upstream code bases.

Hang on, let's avoid playing the blame game. It's perfectly reasonable
to view standards not as holy religious texts that must be adhered to;
these things were written down when specifications were much looser.

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

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.