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, 03 Jun 2024 13:36:40 +0200
From: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
To: "Maciej W. Rozycki" <macro@...am.me.uk>, Linus Torvalds
	 <torvalds@...ux-foundation.org>
Cc: "Paul E. McKenney" <paulmck@...nel.org>, 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>, 
 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

Hi Maciej,

On Mon, 2024-06-03 at 12:09 +0100, Maciej W. Rozycki wrote:
>  Anyway, back to my point.  A feasible solution non-intrusive for Linux 
> and low-overhead for GCC has been found.  I can expedite implementation 
> and I'll see if I can regression-test it too, but I may have to rely on 
> other people to complete it after all, as I haven't been prepared for this 
> effort in the light of certain issues I have recently suffered from in my 
> lab.

That's really great to hear! Please let me know if you have something to test,
I would love to help with this effort.

>  Is that going to be enough to bring the platform bits back?

That would be awesome. Would love to be able to keep running a current kernel
on my AlphaStation 233 which is pre-EV56.

>  FAOD, with all the hacks so eagerly being removed now happily left in the 
> dust bin where they belong, and which I wholeheartedly agree with: we 
> shouldn't be suffering from design mistakes of systems that are no longer 
> relevant, but I fail to see the reason why we should disallow their use 
> where the burden is confined or plain elsewhere.

Agreed.

>  For example we continue supporting old UP MIPS platforms that predate 
> LL/SC, by just trapping and emulating these instructions.  Surely it sucks 
> performance-wise and it's possibly hundreds of cycles too, but it works 
> and the burden is confined to the exception handler, so not a big deal.

Fully agreed.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913