linux-kernel - Re: [PATCH 00/14] alpha: cleanups for 6.10

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2405302248550.23854@angie.orcam.me.uk>
Date: Thu, 30 May 2024 23:59:27 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: "Paul E. McKenney" <paulmck@...nel.org>
cc: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, 
    Arnd Bergmann <arnd@...nel.org>, linux-alpha@...r.kernel.org, 
    Arnd Bergmann <arnd@...db.de>, 
    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>, 
    Marc Zyngier <maz@...nel.org>, 
    Linus Torvalds <torvalds@...ux-foundation.org>, 
    linux-kernel@...r.kernel.org, Michael Cree <mcree@...on.net.nz>, 
    Frank Scheiner <frank.scheiner@....de>
Subject: Re: [PATCH 00/14] alpha: cleanups for 6.10

On Wed, 29 May 2024, Paul E. McKenney wrote:

> >  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).
> 
> See the uses of the fields of the current->rcu_read_unlock_special.b
> anonymous structure for the example that led us here.  And who knows how
> many other pieces of the Linux kernel that assume that it is possible
> to atomically store a single byte.

 Thanks, that helps.

> Many of which use a normal C-language store, in which case there are
> no accessors.  This can be a problem even in the case where there are no
> data races to either byte, because the need for the read-modify-write
> sequence on older Alpha systems results in implicit data races at the
> machine-word level.

 Ack.

> >  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.
> 
> Yes, support has been dropped for some of the older x86 CPUs as well,
> for example, Linux-kernel support for multiprocessor 80386 systems was
> dropped a great many years ago, in part because those CPUs do not have
> a cmpxchg instruction.  So it is not like we are picking on Alpha.

 That's what I mentioned (and for the record i386 wasn't dropped for the 
lack of CMPXCHG, as we never supported i386 SMP, exceedingly rare, anyway, 
but for the lack of page-level write-protection in the kernel mode, which 
implied painful manual checks).  At the time our support for the i386 was 
dropped its population outside embedded use was minuscule and certainly 
compared to non-i386 x86 Linux user base.  And the supply of modern x86 
systems was not an issue either.

 Conversely no new Alpha systems are made and I suspect the ratio between 
BWX and non-BWX Alpha Linux users is not as high as between post-i386 x86 
and original i386 Linux users at the time of the drop.

> >  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.
> 
> I don't know of any remaining issues with the newer Alpha systems that do
> support single-byte and double-byte load and store instructions, and so
> I am not aware of any reason for dropping Linux-kernel support for them.

 Well, the lack of developers to maintain the port would be the reason I 
refer to.  If you let developers drop by preventing them from using their 
hardware to work on the port, then eventually we'll have none.

 Anyway it seems like an issue to be sorted in the compiler, transparently 
to RCU, so it shouldn't be a reason to drop support for non-BWX Alpha CPUs 
anymore.  See my reply to Linus in this thread.

 Thank you for your input, always appreciated.

  Maciej