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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Mon, 3 Jun 2024 12:33:26 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Arnd Bergmann <arnd@...db.de>
cc: "Paul E. McKenney" <paulmck@...nel.org>, 
    John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, 
    Arnd Bergmann <arnd@...nel.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>, 
    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 Fri, 31 May 2024, Arnd Bergmann wrote:

> I then tried changing the underlying variables to 32-bit ones
> to see how many changes are needed, but I gave up after around
> 150 of them, as I was only scratching the surface. To do this
> right, you'd need to go through each one of them and come up
> with a solution that is the best trade-off in terms of memory
> usage and performance for that one. There are of course
> others that should be using WRITE_ONCE() and are missing
> this, so the list is not complete either. See below for
> the ones I could find quickly.

 Thank you for your attempt, and I agree this is excessive and beyond what 
we can reasonably handle.

> >  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.
> 
> I know you like you museum pieces to be older than everyone
> else's, and I'm sorry that my patch series is causing you
> problems, but I don't think the more general criticism is
> valid here. My hope was mainly to help our with both keeping
> Alpha viable for a few more years while also allowing Paul
> to continue with his RCU changes.

 Appreciated and thank you for your appreciation as well.

> As far as I can tell, nobody else is actually using EV4
> machines or has been for years now, but the presence of that
> code did affect both the performance and correctness of the
> kernel code for all EV56+ users since distros have no way
> of picking the ISA level on alpha for a generic kernel.

 Well, at least John Paul Adrian complained as well, and who knows who 
else is there downstream.  I'd expect most people (i.e. all except for 
core Linux developers) not to track upstream development in a continuous 
manner.

> The strongest argument I see for assuming non-BWX alphas
> are long dead is that gcc-4.4 added support for C11 style
> _Atomic variables for alpha, but got the stores wrong
> without anyone ever noticing the problem. Even one makes
> the argument that normal byte stores and volatiles ones
> should not need atomic ll/st sequenes, the atomics
> clearly do. Building BWX-enabled kernels and userland
> completely avoids this problem, which make debugging
> easier for the remaining users when stuff breaks.

 This only shows the lack of proper verification here rather than just 
use.  I'm not even sure if the nature of this problem is going to make it 
trigger in GCC regression testing.  Which BTW I have wired my EV45 system 
for in my lab last year and which would be going by now if not for issues 
with support network automation equipment (FAOD, state of the art and 
supported by the manufacturer).  We shall see once I'm done.

 As John Paul Adrian has pointed out the removal was expedited with no 
attempt made to find a proper solution that would not affect other users.  
As you can see it took me one e-mail exchange with Linus to understand 
what the underlying issue has been and then just a little bit of thinking, 
maybe half an hour, likely even less, to identify a feasible solution.

 Yes, I could have come up with it maybe a month ago if I wasn't so much 
behind on mailing list traffic.  But it's not my day job and since we had 
this issue for years now, it wasn't something that had to be handled as a 
matter of urgency.  We all are people and have our limitations.  We could 
have waited with the RFC out for another development cycle.  This has been 
the point of my complaint.

  Maciej