Message-ID: <a8241a71-2b7d-4be0-8772-5c3b40fb5302@paulmck-laptop>
Date: Sun, 12 May 2024 07:44:25 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
Cc: Arnd Bergmann <arnd@...db.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Linux-Arch <linux-arch@...r.kernel.org>,
	linux-alpha@...r.kernel.org,
	Richard Henderson <richard.henderson@...aro.org>,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Matt Turner <mattst88@...il.com>,
	Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

On Sun, May 12, 2024 at 08:02:59AM +0200, John Paul Adrian Glaubitz wrote:
> On Sat, 2024-05-11 at 18:26 -0700, Paul E. McKenney wrote:
> > And that breaks things because it can clobber concurrent stores to
> > other bytes in that enclosing machine word.
> 
> But pre-EV56 Alpha has always been like this. What makes it broken
> all of a sudden?

I doubt if it was sudden.   Putting concurrently (but rarely) accessed
small-value quantities into single bytes is a very natural thing to do,
and I bet that there are quite a few places in the kernel where exactly
this happens.  I happen to know of a specific instance that went into
mainline about two years ago.

So why didn't the people running current mainline on pre-EV56 Alpha
systems notice?  One possibility is that they are upgrading their
kernels only occasionally.  Another possibility is that they are seeing
the failures, but are not tracing the obtuse failure modes back to the
change(s) in question.  Yet another possibility is that the resulting
failures are very low probability, with mean times to failure that are
so long that you won't notice anything on a single system.

And the change of about two years ago would in fact have a very long
mean time to failure, as in in decades, if not centuries.

But it is still broken, and given a report of a bump-in-the-night failure
on such a system, my response has to be to assume that the inability of
that system to load and store individual bytes is a likely root cause.

> My question was whether it actually stopped working, i.e. it's no
> longer usable on these machines but that's not the case as far as
> I know as not too long ago someone was actually running Debian on
> a Jensen machine [1].

The thing is that I know of one issue.  There are very likely many
others, given that there apparently no checks for this sort of thing.
And as the kernel accumulates (say) seven-decade issues of this sort,
the reliability of your systems declines.

In contrast, if I make the mistake of using the C-language "/" operator
on 64-bit quantities, those affected do not suffer in silence.

> We could actually ask Ulrich Teichert what the current state is
> on his Jensen machine.

Please feel free to do so.

And if the ability to run current mainline reliably on these systems
is so very important to you, please also feel free to look into ways of
fixing this issue within the confines of the Alpha-specific code rather
than attempting to continue placing this outdated constraint on the rest
of the kernel.

Yes, it is no longer the year 1973, but it still is the case that using
four bytes (or, worse yet, per Arnd, eight bytes) where one byte will
do is wasting a huge amount of resources across the billions of systems
on which the Linux kernel runs.  So again, if running current mainline
on these decades-old systems is so very important to you, please figure
out a way to do so that isn't quite so wasteful of resources.

							Thanx, Paul

> Adrian
> 
> > [1] https://marc.info/?l=linux-alpha&m=163265555616841&w=2
> 
> -- 
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer
> `. `'   Physicist
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Powered by blists - more mailing lists