[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdVYiSLOk-zVopXV8i7OZdO7PAK7stZSJNJDMw=ZEqtktA@mail.gmail.com>
Date: Wed, 10 Sep 2025 09:36:34 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Finn Thain <fthain@...ux-m68k.org>
Cc: Kent Overstreet <kent.overstreet@...ux.dev>, 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, 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...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists