Received-SPF: pass (google.com: domain of linux-kernel+bounces-192554-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Tue, 28 May 2024 07:43:34 -0700
From: "Paul E. McKenney" <paulmck@kernel.org>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
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
Message-ID: <aa397ad5-a08a-48a1-a9c0-75cfd5f6a3a5@paulmck-laptop>
Reply-To: paulmck@kernel.org
References: <20240503081125.67990-1-arnd@kernel.org>
 <272a909522f2790a30b9a8be73ab7145bf06d486.camel@physik.fu-berlin.de>
 <alpine.DEB.2.21.2405280041550.23854@angie.orcam.me.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.21.2405280041550.23854@angie.orcam.me.uk>

On Tue, May 28, 2024 at 12:49:16AM +0100, Maciej W. Rozycki wrote:
> On Fri, 3 May 2024, John Paul Adrian Glaubitz wrote:
> 
> > > I had investigated dropping support for alpha EV5 and earlier a while
> > > ago after noticing that this is the only supported CPU family
> > > in the kernel without native byte access and that Debian has already
> > > dropped support for this generation last year [1] after it turned
> > > out to be broken.
> > 
> > That's not quite correct. Support for older Alphas is not broken and
> > always worked when I tested it. It's just that some people wanted to
> > raise the baseline in order to improve code performance on newer machines
> > with the hope to fix some minor issues we saw on Alpha here and there.
> 
>  I'm not quite happy to see pre-EV5 support go as EV45 is all the Alpha 
> hardware I have and it's only owing to issues with the firmware of my 
> console manager hardware that I haven't deployed it at my lab yet for 
> Linux and GNU toolchain verification.  I'd rather I wasn't stuck with an 
> obsolete version of Linux.
> 
> > > 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.

So if you want to run current kernels on old Alphas, you will need to
do something to fix this.

There might well be other things in need of fixing, for but one example,
it might be that the same issue will soon need to be addressed for
two-byte stores.  You will therefore need to carefully investigate this
issue to determine the full extent of work required to solve it.

							Thanx, Paul