linux-kernel - Re: [GIT PULL] alpha: cleanups and build fixes 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, 13 May 2024 09:10:11 +0200
From: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
To: paulmck@...nel.org
Cc: Arnd Bergmann <arnd@...db.de>, Linus Torvalds
 <torvalds@...ux-foundation.org>, linux-kernel@...r.kernel.org, Linux-Arch
 <linux-arch@...r.kernel.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>
Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

Hello,

On Sun, 2024-05-12 at 07:44 -0700, Paul E. McKenney wrote:
> On Sun, May 12, 2024 at 08:02:59AM +0200, John Paul Adrian Glaubitz wrote:
> > On Sat, 2024-05-11 at 18:26 -0700, Paul E. McKenney wrote:
> > > And that breaks things because it can clobber concurrent stores to
> > > other bytes in that enclosing machine word.
> > 
> > But pre-EV56 Alpha has always been like this. What makes it broken
> > all of a sudden?
> 
> I doubt if it was sudden.   Putting concurrently (but rarely) accessed
> small-value quantities into single bytes is a very natural thing to do,
> and I bet that there are quite a few places in the kernel where exactly
> this happens.  I happen to know of a specific instance that went into
> mainline about two years ago.

But it's treated like it happened all of a sudden instead of taking the way
of a proper phaseout. That's what I am criticizing.

> > We could actually ask Ulrich Teichert what the current state is
> > on his Jensen machine.
> 
> Please feel free to do so.
> 
> And if the ability to run current mainline reliably on these systems
> is so very important to you, please also feel free to look into ways of
> fixing this issue within the confines of the Alpha-specific code rather
> than attempting to continue placing this outdated constraint on the rest
> of the kernel.

Well, we have had a similar discussion just a few months before with the
ia64 removal. But in that case we agreed that a good compromise would be
to slate the removal for an LTS release so that users would be able to use
an LTS kernel on these machines.

I'm not sure why this shouldn't be possible in this case as well.

> Yes, it is no longer the year 1973, but it still is the case that using
> four bytes (or, worse yet, per Arnd, eight bytes) where one byte will
> do is wasting a huge amount of resources across the billions of systems
> on which the Linux kernel runs.  So again, if running current mainline
> on these decades-old systems is so very important to you, please figure
> out a way to do so that isn't quite so wasteful of resources.

The way this whole change was pushed through doesn't sound like you're willing
to give people the time to find an alternative solution. The pre-EV56 removal
was pushed through without any further discussion with the claim that pre-EV56
support is broken.

Is that not something that can be criticized?

Adrian

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