From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Arnd Bergmann <arnd@kernel.org>,
linux-alpha@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
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>,
Marc Zyngier <maz@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, Michael Cree <mcree@orcon.net.nz>,
Frank Scheiner <frank.scheiner@web.de>
Subject: Re: [PATCH 00/14] alpha: cleanups for 6.10
Date: Wed, 29 May 2024 19:50:28 +0100 (BST) [thread overview]
Message-ID: <alpine.DEB.2.21.2405291432450.23854@angie.orcam.me.uk> (raw)
In-Reply-To: <aa397ad5-a08a-48a1-a9c0-75cfd5f6a3a5@paulmck-laptop>
On Tue, 28 May 2024, Paul E. McKenney wrote:
> > > > This topic came up again when Paul E. McKenney noticed that
> > > > parts of the RCU code already rely on byte access and do not
> > > > work on alpha EV5 reliably, so I refreshed my series now for
> > > > inclusion into the next merge window.
> > >
> > > Hrrrm? That sounds like like Paul ran tests on EV5, did he?
> >
> > What exactly is required to make it work?
>
> Whatever changes are needed to prevent the data corruption that can
> currently result in code generated by single-byte stores. For but one
> example, consider a pair of tasks (or one task and an interrupt handler
> in the CONFIG_SMP=n case) do a single-byte store to a pair of bytes
> in the same machine word. As I understand it, in code generated for
> older Alphas, both "stores" will load the word containing that byte,
> update their own byte, and store the updated word.
>
> If two such single-byte stores run concurrently, one or the other of those
> two stores will be lost, as in overwritten by the other. This is a bug,
> even in kernels built for single-CPU systems. And a rare bug at that, one
> that tends to disappear as you add debug code in an attempt to find it.
Thank you for the detailed description of the problematic scenario.
I hope someone will find it useful, however for the record I have been
familiar with the intricacies of the Alpha architecture as well as their
implications for software for decades now. The Alpha port of Linux was
the first non-x86 Linux platform I have used and actually (and I've chased
that as a matter of interest) my first ever contribution to Linux was for
Alpha platform code:
On Mon, 30 Mar 1998, Jay.Estabrook@digital.com wrote:
> Hi, sorry about the delay in answering, but you'll be happy to know, I took
> your patches and merged them into my latest SMP patches, and submitted them
> to Linus just last night. He promises them to (mostly) be in 2.1.92, so we
> can look forward to that... :-)
so I find the scenario you have described more than obvious.
Mind that the read-modify-write sequence that software does for sub-word
write accesses with original Alpha hardware is precisely what hardware
would have to do anyway and support for that was deliberately omitted by
the architecture designers from the ISA to give it performance advantages
quoted in the architecture manual. The only difference here is that with
hardware read-modify-write operations atomicity for sub-word accesses is
guaranteed by the ISA, however for software read-modify-write it has to be
explictly coded using the usual load-locked/store-conditional sequence in
a loop. I don't think it's a big deal really, it should be trivial to do
in the relevant accessors, along with the memory barriers that are needed
anyway for EV56+ and possibly other ports such as the MIPS one.
What I have been after actually is: can you point me at a piece of code
in our tree that will cause an issue with a non-BWX Alpha as described in
your scenario, so that I have a starting point? Mind that I'm completely
new to RCU as I didn't have a need to research it before (though from a
skim over Documentation/RCU/rcu.rst I understand what its objective is).
FWIW even if it was only me I think that depriving the already thin Alpha
port developer base of any quantity of the remaining manpower, by dropping
support for a subset of the hardware available, and then a subset that is
not just as exotic as the original i386 became to the x86 platform at the
time support for it was dropped, is only going to lead to further demise
and eventual drop of the entire port.
And I think it would be good if we kept the port, just as we keep other
ports of historical significance only, for educational reasons if nothing
else, such as to let people understand based on an actual example, once
mainstream, the implications of weakly ordered memory systems.
Maciej
next prev parent reply other threads:[~2024-05-29 18:50 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 8:11 [PATCH 00/14] alpha: cleanups for 6.10 Arnd Bergmann
2024-05-03 8:11 ` [PATCH 01/14] alpha: sort scr_mem{cpy,move}w() out Arnd Bergmann
2024-05-03 8:11 ` [PATCH 02/14] alpha: fix modversions for strcpy() et.al Arnd Bergmann
2024-05-03 8:11 ` [PATCH 03/14] alpha: add clone3() support Arnd Bergmann
2024-05-03 8:11 ` [PATCH 04/14] alpha: don't make functions public without a reason Arnd Bergmann
2024-05-03 8:11 ` [PATCH 05/14] alpha: sys_sio: fix misspelled ifdefs Arnd Bergmann
2024-05-03 8:11 ` [PATCH 06/14] alpha: missing includes Arnd Bergmann
2024-05-03 8:11 ` [PATCH 07/14] alpha: core_lca: take the unused functions out Arnd Bergmann
2024-05-03 8:11 ` [PATCH 08/14] alpha: jensen, t2 - make __EXTERN_INLINE same as for the rest Arnd Bergmann
2024-05-03 8:11 ` [PATCH 09/14] alpha: trim the unused stuff from asm-offsets.c Arnd Bergmann
2024-05-03 8:11 ` [PATCH 10/14] alpha: remove DECpc AXP150 (Jensen) support Arnd Bergmann
2024-05-03 16:07 ` Linus Torvalds
2024-05-03 17:00 ` Al Viro
2024-05-03 20:07 ` Arnd Bergmann
2024-05-03 8:11 ` [PATCH 11/14] alpha: sable: remove early machine support Arnd Bergmann
2024-05-03 8:11 ` [PATCH 12/14] alpha: remove LCA and APECS based machines Arnd Bergmann
2024-05-03 8:11 ` [PATCH 13/14] alpha: cabriolet: remove EV5 CPU support Arnd Bergmann
2024-05-03 8:11 ` [PATCH 14/14] alpha: drop pre-EV56 support Arnd Bergmann
2024-05-04 15:00 ` Richard Henderson
2024-05-06 10:06 ` Arnd Bergmann
2024-06-03 6:02 ` Jiri Slaby
2024-06-04 13:58 ` Greg KH
2024-05-03 16:06 ` [PATCH 00/14] alpha: cleanups for 6.10 Matt Turner
2024-05-03 20:15 ` Arnd Bergmann
2024-05-06 9:16 ` Michael Cree
2024-05-06 10:11 ` Arnd Bergmann
2024-05-03 16:53 ` John Paul Adrian Glaubitz
2024-05-03 17:19 ` Paul E. McKenney
2024-05-27 23:49 ` Maciej W. Rozycki
2024-05-28 14:43 ` Paul E. McKenney
2024-05-29 18:50 ` Maciej W. Rozycki [this message]
2024-05-29 22:09 ` Paul E. McKenney
2024-05-30 22:59 ` Maciej W. Rozycki
2024-05-31 3:56 ` Maciej W. Rozycki
2024-05-31 19:33 ` Paul E. McKenney
2024-06-03 16:22 ` Maciej W. Rozycki
2024-06-03 17:08 ` Paul E. McKenney
2024-07-01 23:50 ` Maciej W. Rozycki
2024-05-30 1:08 ` Linus Torvalds
2024-05-30 22:57 ` Maciej W. Rozycki
2024-05-31 0:10 ` Linus Torvalds
2024-06-03 11:09 ` Maciej W. Rozycki
2024-06-03 11:36 ` John Paul Adrian Glaubitz
2024-06-03 16:57 ` Linus Torvalds
2024-07-01 23:48 ` Maciej W. Rozycki
2024-05-31 15:48 ` Arnd Bergmann
2024-05-31 16:32 ` Linus Torvalds
2024-05-31 16:54 ` Arnd Bergmann
2024-06-01 13:51 ` David Laight
2024-07-01 23:48 ` Maciej W. Rozycki
2024-07-02 1:13 ` Linus Torvalds
2024-07-03 0:12 ` Maciej W. Rozycki
2024-07-03 0:50 ` Linus Torvalds
2024-07-04 22:21 ` Maciej W. Rozycki
2024-06-03 11:33 ` Maciej W. Rozycki
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=alpine.DEB.2.21.2405291432450.23854@angie.orcam.me.uk \
--to=macro@orcam.me.uk \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=frank.scheiner@web.de \
--cc=glaubitz@physik.fu-berlin.de \
--cc=ink@jurassic.park.msu.ru \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mattst88@gmail.com \
--cc=maz@kernel.org \
--cc=mcree@orcon.net.nz \
--cc=paulmck@kernel.org \
--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).