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] [day] [month] [year] [list]

Message-ID: <inscijwnnydibdwwrkggvgxjtimajr5haixff77dbd7cxvvwc7@2t7l7oegsxcp>
Date: Wed, 10 Sep 2025 07:57:01 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Finn Thain <fthain@...ux-m68k.org>, Lance Yang <lance.yang@...ux.dev>, 
	akpm@...ux-foundation.org, amaindex@...look.com, anna.schumaker@...cle.com, 
	boqun.feng@...il.com, 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 09:36:34AM +0200, Geert Uytterhoeven wrote:
> On Wed, 10 Sept 2025 at 02:07, Finn Thain <fthain@...ux-m68k.org> 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.
> >
> > 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.
> >
> > 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].
> >
> > Linux is probably the only non-trivial program that could be feasibly
> > rebuilt with -malign-int without ill effect (i.e. without breaking
> > userland) but that sort of workaround would not address the root cause
> > (i.e. algorithms with bad assumptions).
> 
> The first step to preserve compatibility with userland would be to
> properly annotate the few uapi definitions that would change with
> -malign-int otherwise.  I am still waiting for these patches...

I think it'd need a new gcc attribute to do it sanely...