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

[Finn Thain <fthain@linux-m68k.org>]

On Tue, 9 Sep 2025, Kent Overstreet wrote:

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

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.

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

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