From: "Paul E. McKenney" <paulmck@kernel.org>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Arnd Bergmann <arnd@arndb.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Linux-Arch <linux-arch@vger.kernel.org>,
linux-alpha@vger.kernel.org,
Richard Henderson <richard.henderson@linaro.org>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
Date: Sun, 12 May 2024 07:44:25 -0700 [thread overview]
Message-ID: <a8241a71-2b7d-4be0-8772-5c3b40fb5302@paulmck-laptop> (raw)
In-Reply-To: <975442500864e4f30a830afb4ffd09a9bedb65d6.camel@physik.fu-berlin.de>
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
next prev parent reply other threads:[~2024-05-12 14:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-10 21:17 [GIT PULL] asm-generic cleanups for 6.10 Arnd Bergmann
2024-05-10 21:19 ` [GIT PULL] alpha: cleanups and build fixes " Arnd Bergmann
2024-05-10 21:40 ` John Paul Adrian Glaubitz
2024-05-10 22:28 ` Paul E. McKenney
2024-05-11 18:49 ` John Paul Adrian Glaubitz
2024-05-11 19:37 ` Paul E. McKenney
2024-05-11 20:08 ` Arnd Bergmann
2024-05-12 1:26 ` Paul E. McKenney
2024-05-12 6:02 ` John Paul Adrian Glaubitz
2024-05-12 14:44 ` Paul E. McKenney [this message]
2024-05-13 3:50 ` Akira Yokosawa
2024-05-13 4:03 ` Paul E. McKenney
2024-05-13 6:28 ` Arnd Bergmann
2024-05-13 9:26 ` John Paul Adrian Glaubitz
2024-05-13 16:52 ` Ulrich Teichert
2024-05-13 21:44 ` John Paul Adrian Glaubitz
2024-05-13 7:10 ` John Paul Adrian Glaubitz
2024-05-12 6:17 ` John Paul Adrian Glaubitz
2024-05-13 16:27 ` Linus Torvalds
2024-05-13 21:42 ` John Paul Adrian Glaubitz
2024-05-13 17:05 ` pr-tracker-bot
2024-05-13 16:11 ` [GIT PULL] asm-generic cleanups " Linus Torvalds
2024-05-13 16:36 ` Arnd Bergmann
2024-05-20 22:35 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a8241a71-2b7d-4be0-8772-5c3b40fb5302@paulmck-laptop \
--to=paulmck@kernel.org \
--cc=arnd@arndb.de \
--cc=glaubitz@physik.fu-berlin.de \
--cc=ink@jurassic.park.msu.ru \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mattst88@gmail.com \
--cc=richard.henderson@linaro.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).