LinuxLists.cc - [GIT PULL] asm-generic cleanups for 6.10

[permalink] [raw]

Subject: [GIT PULL] alpha: cleanups and build fixes for 6.10

The following changes since commit fec50db7033ea478773b159e0e2efb135270e3b7:

Linux 6.9-rc3 (2024-04-07 13:22:46 -0700)

are available in the Git repository at:

https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git tags/asm-generic-alpha

for you to fetch changes up to a4184174be36369c3af8d937e165f28a43ef1e02:

alpha: drop pre-EV56 support (2024-05-06 12:05:00 +0200)

----------------------------------------------------------------
alpha: cleanups and build fixes

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] in order to
improve performance for the newer machines.

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 we decided on using my series to
avoid the problem entirely.

Al Viro did another series for alpha to address all the known build
issues. I rebased his patches without any further changes and included
it as a baseline for my work here to avoid conflicts and allow
backporting the fixes to stable kernels for the now removed hardware
support as well.

----------------------------------------------------------------
Al Viro (9):
alpha: sort scr_mem{cpy,move}w() out
alpha: fix modversions for strcpy() et.al.
alpha: add clone3() support
alpha: don't make functions public without a reason
alpha: sys_sio: fix misspelled ifdefs
alpha: missing includes
alpha: core_lca: take the unused functions out
alpha: jensen, t2 - make __EXTERN_INLINE same as for the rest
alpha: trim the unused stuff from asm-offsets.c

Arnd Bergmann (5):
alpha: remove DECpc AXP150 (Jensen) support
alpha: sable: remove early machine support
alpha: remove LCA and APECS based machines
alpha: cabriolet: remove EV5 CPU support
alpha: drop pre-EV56 support

Documentation/driver-api/eisa.rst | 4 +-
arch/alpha/Kconfig | 175 +----------
arch/alpha/Makefile | 8 +-
arch/alpha/include/asm/core_apecs.h | 534 ---------------------------------
arch/alpha/include/asm/core_lca.h | 378 -----------------------
arch/alpha/include/asm/core_t2.h | 8 -
arch/alpha/include/asm/dma-mapping.h | 4 -
arch/alpha/include/asm/dma.h | 9 +-
arch/alpha/include/asm/elf.h | 4 +-
arch/alpha/include/asm/io.h | 26 +-
arch/alpha/include/asm/irq.h | 10 +-
arch/alpha/include/asm/jensen.h | 363 ----------------------
arch/alpha/include/asm/machvec.h | 9 -
arch/alpha/include/asm/mmu_context.h | 45 +--
arch/alpha/include/asm/special_insns.h | 5 +-
arch/alpha/include/asm/tlbflush.h | 37 +--
arch/alpha/include/asm/uaccess.h | 80 -----
arch/alpha/include/asm/vga.h | 2 +
arch/alpha/include/uapi/asm/compiler.h | 18 --
arch/alpha/kernel/Makefile | 25 +-
arch/alpha/kernel/asm-offsets.c | 21 +-
arch/alpha/kernel/bugs.c | 1 +
arch/alpha/kernel/console.c | 1 +
arch/alpha/kernel/core_apecs.c | 420 --------------------------
arch/alpha/kernel/core_cia.c | 6 +-
arch/alpha/kernel/core_irongate.c | 1 -
arch/alpha/kernel/core_lca.c | 517 -------------------------------
arch/alpha/kernel/core_marvel.c | 2 +-
arch/alpha/kernel/core_t2.c | 2 +-
arch/alpha/kernel/core_wildfire.c | 8 +-
arch/alpha/kernel/entry.S | 1 +
arch/alpha/kernel/io.c | 19 ++
arch/alpha/kernel/irq.c | 1 +
arch/alpha/kernel/irq_i8259.c | 4 -
arch/alpha/kernel/machvec_impl.h | 25 +-
arch/alpha/kernel/pci-noop.c | 113 -------
arch/alpha/kernel/pci_impl.h | 4 +-
arch/alpha/kernel/perf_event.c | 2 +-
arch/alpha/kernel/proto.h | 44 +--
arch/alpha/kernel/setup.c | 109 +------
arch/alpha/kernel/smc37c669.c | 6 +-
arch/alpha/kernel/smc37c93x.c | 2 +
arch/alpha/kernel/smp.c | 1 +
arch/alpha/kernel/srmcons.c | 2 +
arch/alpha/kernel/sys_cabriolet.c | 87 +-----
arch/alpha/kernel/sys_eb64p.c | 238 ---------------
arch/alpha/kernel/sys_jensen.c | 237 ---------------
arch/alpha/kernel/sys_mikasa.c | 57 ----
arch/alpha/kernel/sys_nautilus.c | 8 +-
arch/alpha/kernel/sys_noritake.c | 60 ----
arch/alpha/kernel/sys_sable.c | 294 +-----------------
arch/alpha/kernel/sys_sio.c | 486 ------------------------------
arch/alpha/kernel/syscalls/syscall.tbl | 2 +-
arch/alpha/kernel/traps.c | 64 ----
arch/alpha/lib/Makefile | 14 -
arch/alpha/lib/checksum.c | 1 +
arch/alpha/lib/fpreg.c | 1 +
arch/alpha/lib/memcpy.c | 3 +
arch/alpha/lib/stycpy.S | 11 +
arch/alpha/lib/styncpy.S | 11 +
arch/alpha/math-emu/math.c | 7 +-
arch/alpha/mm/init.c | 2 +-
drivers/char/agp/alpha-agp.c | 2 +-
drivers/eisa/Kconfig | 9 +-
drivers/eisa/virtual_root.c | 2 +-
drivers/input/serio/i8042-io.h | 5 +-
drivers/tty/serial/8250/8250.h | 3 -
drivers/tty/serial/8250/8250_alpha.c | 21 --
drivers/tty/serial/8250/8250_core.c | 4 -
drivers/tty/serial/8250/Makefile | 2 -
include/linux/blk_types.h | 6 -
include/linux/tty.h | 14 +-
72 files changed, 166 insertions(+), 4541 deletions(-)
delete mode 100644 arch/alpha/include/asm/core_apecs.h
delete mode 100644 arch/alpha/include/asm/core_lca.h
delete mode 100644 arch/alpha/include/asm/jensen.h
delete mode 100644 arch/alpha/kernel/core_apecs.c
delete mode 100644 arch/alpha/kernel/core_lca.c
delete mode 100644 arch/alpha/kernel/pci-noop.c
delete mode 100644 arch/alpha/kernel/sys_eb64p.c
delete mode 100644 arch/alpha/kernel/sys_jensen.c
delete mode 100644 arch/alpha/kernel/sys_sio.c
create mode 100644 arch/alpha/lib/stycpy.S
create mode 100644 arch/alpha/lib/styncpy.S
delete mode 100644 drivers/tty/serial/8250/8250_alpha.c

2024-05-10 21:47:42

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

On Fri, 2024-05-10 at 23:19 +0200, Arnd Bergmann wrote:
> The following changes since commit fec50db7033ea478773b159e0e2efb135270e3b7:
>
> Linux 6.9-rc3 (2024-04-07 13:22:46 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git tags/asm-generic-alpha
>
> for you to fetch changes up to a4184174be36369c3af8d937e165f28a43ef1e02:
>
> alpha: drop pre-EV56 support (2024-05-06 12:05:00 +0200)

I'm still against dropping pre-EV56 so quickly without a proper phaseout period.
Why not wait for the next LTS release? AFAIK pre-EV56 support is not broken, is
it?

Adrian

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

2024-05-10 22:28:09

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

On Fri, May 10, 2024 at 11:40:04PM +0200, John Paul Adrian Glaubitz wrote:
> On Fri, 2024-05-10 at 23:19 +0200, Arnd Bergmann wrote:
> > The following changes since commit fec50db7033ea478773b159e0e2efb135270e3b7:
> >
> > Linux 6.9-rc3 (2024-04-07 13:22:46 -0700)
> >
> > are available in the Git repository at:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git tags/asm-generic-alpha
> >
> > for you to fetch changes up to a4184174be36369c3af8d937e165f28a43ef1e02:
> >
> > alpha: drop pre-EV56 support (2024-05-06 12:05:00 +0200)
>
> I'm still against dropping pre-EV56 so quickly without a proper phaseout period.
> Why not wait for the next LTS release? AFAIK pre-EV56 support is not broken, is
> it?

Sadly, yes, it is, and it has been broken in mainline for almost two
years.

Thanx, Paul

2024-05-11 18:49:37

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

Hi Paul,

On Fri, 2024-05-10 at 15:28 -0700, Paul E. McKenney wrote:
> > I'm still against dropping pre-EV56 so quickly without a proper phaseout period.
> > Why not wait for the next LTS release? AFAIK pre-EV56 support is not broken, is
> > it?
>
> Sadly, yes, it is, and it has been broken in mainline for almost two
> years.

Could you elaborate what exactly is broken? I'm just trying to understand the reasoning.

Adrian

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

2024-05-11 19:37:09

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

On Sat, May 11, 2024 at 08:49:08PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Paul,
>
> On Fri, 2024-05-10 at 15:28 -0700, Paul E. McKenney wrote:
> > > I'm still against dropping pre-EV56 so quickly without a proper phaseout period.
> > > Why not wait for the next LTS release? AFAIK pre-EV56 support is not broken, is
> > > it?
> >
> > Sadly, yes, it is, and it has been broken in mainline for almost two
> > years.
>
> Could you elaborate what exactly is broken? I'm just trying to understand the reasoning.

First, let's make sure that I completely and correctly understand the
situation.

The pre-EV56 Alphas have no byte store instruction, correct?

If that is in fact correct, what code is generated for a volatile store
to a single byte for those CPUs? For example, for this example?

char c;

...

WRITE_ONCE(c, 3);

The rumor I heard is that the compilers will generate a non-atomic
read-modify-write instruction sequence in this case, first reading the
32-bit word containing that byte into a register, then substituting the
value to be stored into corresponding byte of that register, and finally
doing a 32-bit store from that register.

Is that the case, or am I confused?

Thanx, Paul

PS: Or, if you prefer, this example is equivalent:

volatile char c;

...

c = 3;

2024-05-11 20:09:41

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

On Sat, May 11, 2024, at 21:37, Paul E. McKenney wrote:
> On Sat, May 11, 2024 at 08:49:08PM +0200, John Paul Adrian Glaubitz wrote:
>
> The pre-EV56 Alphas have no byte store instruction, correct?
>
> If that is in fact correct, what code is generated for a volatile store
> to a single byte for those CPUs? For example, for this example?
>
> char c;
>
> ...
>
> WRITE_ONCE(c, 3);
>
> The rumor I heard is that the compilers will generate a non-atomic
> read-modify-write instruction sequence in this case, first reading the
> 32-bit word containing that byte into a register, then substituting the
> value to be stored into corresponding byte of that register, and finally
> doing a 32-bit store from that register.
>
> Is that the case, or am I confused?

I think it's slightly worse: gcc will actually do a 64-bit
read-modify-write rather than a 32-bit one, and it doesn't
use atomic ll/sc when storing into an _Atomic struct member:

echo '#include <stdatomic.h>^M struct s { _Atomic char c; _Atomic char s[7]; long l; }; void f(struct s *s) { atomic_store(&s->c, 3); }' | alpha-linux-gcc-14 -xc - -S -o- -O2 -mcpu=ev5

f:
.frame $30,0,$26,0
$LFB0:
.cfi_startproc
.prologue 0
mb
lda $1,3($31)
insbl $1,$16,$1
ldq_u $2,0($16)
mskbl $2,$16,$2
bis $1,$2,$1
stq_u $1,0($16)
bis $31,$31,$31
mb
ret $31,($26),1
.cfi_endproc
$LFE0:
.end f

compared to -mcpu=ev56:

f:
.frame $30,0,$26,0
$LFB0:
.cfi_startproc
.prologue 0
mb
lda $1,3($31)
stb $1,0($16)
bis $31,$31,$31
mb
ret $31,($26),1
.cfi_endproc
$LFE0:
.end f

Arnd

2024-05-12 01:26:21

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

On Sat, May 11, 2024 at 10:08:50PM +0200, Arnd Bergmann wrote:
> On Sat, May 11, 2024, at 21:37, Paul E. McKenney wrote:
> > On Sat, May 11, 2024 at 08:49:08PM +0200, John Paul Adrian Glaubitz wrote:
> >
> > The pre-EV56 Alphas have no byte store instruction, correct?
> >
> > If that is in fact correct, what code is generated for a volatile store
> > to a single byte for those CPUs? For example, for this example?
> >
> > char c;
> >
> > ...
> >
> > WRITE_ONCE(c, 3);
> >
> > The rumor I heard is that the compilers will generate a non-atomic
> > read-modify-write instruction sequence in this case, first reading the
> > 32-bit word containing that byte into a register, then substituting the
> > value to be stored into corresponding byte of that register, and finally
> > doing a 32-bit store from that register.
> >
> > Is that the case, or am I confused?
>
> I think it's slightly worse: gcc will actually do a 64-bit
> read-modify-write rather than a 32-bit one, and it doesn't
> use atomic ll/sc when storing into an _Atomic struct member:
>
> echo '#include <stdatomic.h>^M struct s { _Atomic char c; _Atomic char s[7]; long l; }; void f(struct s *s) { atomic_store(&s->c, 3); }' | alpha-linux-gcc-14 -xc - -S -o- -O2 -mcpu=ev5
>
> f:
> .frame $30,0,$26,0
> $LFB0:
> .cfi_startproc
> .prologue 0
> mb
> lda $1,3($31)
> insbl $1,$16,$1
> ldq_u $2,0($16)
> mskbl $2,$16,$2
> bis $1,$2,$1
> stq_u $1,0($16)
> bis $31,$31,$31
> mb
> ret $31,($26),1
> .cfi_endproc
> $LFE0:
> .end f
>
> compared to -mcpu=ev56:
>
> f:
> .frame $30,0,$26,0
> $LFB0:
> .cfi_startproc
> .prologue 0
> mb
> lda $1,3($31)
> stb $1,0($16)
> bis $31,$31,$31
> mb
> ret $31,($26),1
> .cfi_endproc
> $LFE0:
> .end f

Thank you, Arnd!

And that breaks things because it can clobber concurrent stores to
other bytes in that enclosing machine word.

Thanx, Paul

2024-05-12 06:03:21

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

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?

My question was whether it actually stopped working, i.e. it's no
longer usable on these machines but that's not the case as far as
I know as not too long ago someone was actually running Debian on
a Jensen machine [1].

We could actually ask Ulrich Teichert what the current state is
on his Jensen machine.

Adrian

> [1] https://marc.info/?l=linux-alpha&m=163265555616841&w=2

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

2024-05-12 06:17:42

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

Hi Ulrich,

On Fri, 2024-05-10 at 23:19 +0200, Arnd Bergmann wrote:
> The following changes since commit fec50db7033ea478773b159e0e2efb135270e3b7:
>
> Linux 6.9-rc3 (2024-04-07 13:22:46 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git tags/asm-generic-alpha
>
> for you to fetch changes up to a4184174be36369c3af8d937e165f28a43ef1e02:
>
> alpha: drop pre-EV56 support (2024-05-06 12:05:00 +0200)
>
> ----------------------------------------------------------------
> alpha: cleanups and build fixes
>
> 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] in order to
> improve performance for the newer machines.
>
> 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 we decided on using my series to
> avoid the problem entirely.
>
> Al Viro did another series for alpha to address all the known build
> issues. I rebased his patches without any further changes and included
> it as a baseline for my work here to avoid conflicts and allow
> backporting the fixes to stable kernels for the now removed hardware
> support as well.
>
> ----------------------------------------------------------------
> Al Viro (9):
> alpha: sort scr_mem{cpy,move}w() out
> alpha: fix modversions for strcpy() et.al.
> alpha: add clone3() support
> alpha: don't make functions public without a reason
> alpha: sys_sio: fix misspelled ifdefs
> alpha: missing includes
> alpha: core_lca: take the unused functions out
> alpha: jensen, t2 - make __EXTERN_INLINE same as for the rest
> alpha: trim the unused stuff from asm-offsets.c
>
> Arnd Bergmann (5):
> alpha: remove DECpc AXP150 (Jensen) support
> alpha: sable: remove early machine support
> alpha: remove LCA and APECS based machines
> alpha: cabriolet: remove EV5 CPU support
> alpha: drop pre-EV56 support

There are currently efforts to remove kernel support for older Alpha machines
before EV56 such as the Jensen machines and I was wondering what the current
status of the Linux kernel on your machine was.

Arnd and Paul claim it's broken and no longer works, but not too long ago you
confirmed that Linux 5.14 booted fine on your machine.

Do you have any current data?

Thanks,
Adrian

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

2024-05-12 14:44:37

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

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.

So why didn't the people running current mainline on pre-EV56 Alpha
systems notice? One possibility is that they are upgrading their
kernels only occasionally. Another possibility is that they are seeing
the failures, but are not tracing the obtuse failure modes back to the
change(s) in question. Yet another possibility is that the resulting
failures are very low probability, with mean times to failure that are
so long that you won't notice anything on a single system.

And the change of about two years ago would in fact have a very long
mean time to failure, as in in decades, if not centuries.

But it is still broken, and given a report of a bump-in-the-night failure
on such a system, my response has to be to assume that the inability of
that system to load and store individual bytes is a likely root cause.

> My question was whether it actually stopped working, i.e. it's no
> longer usable on these machines but that's not the case as far as
> I know as not too long ago someone was actually running Debian on
> a Jensen machine [1].

The thing is that I know of one issue. There are very likely many
others, given that there apparently no checks for this sort of thing.
And as the kernel accumulates (say) seven-decade issues of this sort,
the reliability of your systems declines.

In contrast, if I make the mistake of using the C-language "/" operator
on 64-bit quantities, those affected do not suffer in silence.

> 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.

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.

Thanx, Paul

> Adrian
>
> > [1] https://marc.info/?l=linux-alpha&m=163265555616841&w=2
>
> --
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer
> `. `' Physicist
> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

2024-05-13 03:50:24

by Akira Yokosawa

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

On Sun, 12 May 2024 07:44:25 -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.
>
> So why didn't the people running current mainline on pre-EV56 Alpha
> systems notice? One possibility is that they are upgrading their
> kernels only occasionally. Another possibility is that they are seeing
> the failures, but are not tracing the obtuse failure modes back to the
> change(s) in question. Yet another possibility is that the resulting
> failures are very low probability, with mean times to failure that are
> so long that you won't notice anything on a single system.

Another possibility is that the Jensen system was booted into uni processer
mode. Looking at the early boot log [1] provided by Ulrich (+CCed) back in
Sept. 2021, I see the following by running "grep -i cpu":

>> > [1] https://marc.info/?l=linux-alpha&m=163265555616841&w=2

[ 0.000000] Memory: 90256K/131072K available (8897K kernel code, 9499K rwdata, \
2704K rodata, 312K init, 437K bss, 40816K reserved, 0K cma-reserved) [ 0.000000] \
random: get_random_u64 called from __kmem_cache_create+0x54/0x600 with crng_init=0 [ \
0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000]
^^^^^^

Without any concurrent atomic updates, the "broken" atomic accesses won't
matter, I guess.

Thanks, Akira

2024-05-13 04:03:26

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

On Mon, May 13, 2024 at 12:50:07PM +0900, Akira Yokosawa wrote:
> On Sun, 12 May 2024 07:44:25 -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.
> >
> > So why didn't the people running current mainline on pre-EV56 Alpha
> > systems notice? One possibility is that they are upgrading their
> > kernels only occasionally. Another possibility is that they are seeing
> > the failures, but are not tracing the obtuse failure modes back to the
> > change(s) in question. Yet another possibility is that the resulting
> > failures are very low probability, with mean times to failure that are
> > so long that you won't notice anything on a single system.
>
> Another possibility is that the Jensen system was booted into uni processer
> mode. Looking at the early boot log [1] provided by Ulrich (+CCed) back in
> Sept. 2021, I see the following by running "grep -i cpu":
>
> >> > [1] https://marc.info/?l=linux-alpha&m=163265555616841&w=2
>
> [ 0.000000] Memory: 90256K/131072K available (8897K kernel code, 9499K rwdata, \
> 2704K rodata, 312K init, 437K bss, 40816K reserved, 0K cma-reserved) [ 0.000000] \
> random: get_random_u64 called from __kmem_cache_create+0x54/0x600 with crng_init=0 [ \
> 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000]
> ^^^^^^
>
> Without any concurrent atomic updates, the "broken" atomic accesses won't
> matter, I guess.

True enough!

Thanx, Paul

2024-05-13 06:29:07

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

On Mon, May 13, 2024, at 06:03, Paul E. McKenney wrote:
> On Mon, May 13, 2024 at 12:50:07PM +0900, Akira Yokosawa wrote:
>> On Sun, 12 May 2024 07:44:25 -0700, Paul E. McKenney wrote:
>> > On Sun, May 12, 2024 at 08:02:59AM +0200, John Paul Adrian Glaubitz wrote:
>> > So why didn't the people running current mainline on pre-EV56 Alpha
>> > systems notice? One possibility is that they are upgrading their
>> > kernels only occasionally. Another possibility is that they are seeing
>> > the failures, but are not tracing the obtuse failure modes back to the
>> > change(s) in question. Yet another possibility is that the resulting
>> > failures are very low probability, with mean times to failure that are
>> > so long that you won't notice anything on a single system.
>>
>> Another possibility is that the Jensen system was booted into uni processer
>> mode. Looking at the early boot log [1] provided by Ulrich (+CCed) back in
>> Sept. 2021, I see the following by running "grep -i cpu":
>>
>> >> > [1] https://marc.info/?l=linux-alpha&m=163265555616841&w=2
>>
>> [ 0.000000] Memory: 90256K/131072K available (8897K kernel code, 9499K rwdata, \
>> 2704K rodata, 312K init, 437K bss, 40816K reserved, 0K cma-reserved) [ 0.000000] \
>> random: get_random_u64 called from __kmem_cache_create+0x54/0x600 with crng_init=0 [ \
>> 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000]
>> ^^^^^^
>>
>> Without any concurrent atomic updates, the "broken" atomic accesses won't
>> matter, I guess.
>
> True enough!

On the other hand, you would get the same broken behavior on
any SMP machine running a kernel that has support for EV5 or
earlier enabled in a multiplatform kernel. It doesn't really
matter if it's running on hardware that supports BWX or not
as long as the compiler doesn't generate those instructions.

If I understand it correctly, simply running rcutorture on
a large alpha machine with a 'defconfig' kernel from the
past two years should trigger some bugs even if you don't
run into them that frequently on light usage, right?

Arnd

2024-05-13 07:10:31

[permalink] [raw]

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

2024-05-13 09:26:54

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

On Mon, 2024-05-13 at 12:50 +0900, Akira Yokosawa wrote:
> > So why didn't the people running current mainline on pre-EV56 Alpha
> > systems notice? One possibility is that they are upgrading their
> > kernels only occasionally. Another possibility is that they are seeing
> > the failures, but are not tracing the obtuse failure modes back to the
> > change(s) in question. Yet another possibility is that the resulting
> > failures are very low probability, with mean times to failure that are
> > so long that you won't notice anything on a single system.
>
> Another possibility is that the Jensen system was booted into uni processer
> mode. Looking at the early boot log [1] provided by Ulrich (+CCed) back in
> Sept. 2021, I see the following by running "grep -i cpu":
>
> > > > [1] https://marc.info/?l=linux-alpha&m=163265555616841&w=2
>
> [ 0.000000] Memory: 90256K/131072K available (8897K kernel code, 9499K rwdata, \
> 2704K rodata, 312K init, 437K bss, 40816K reserved, 0K cma-reserved) [ 0.000000] \
> random: get_random_u64 called from __kmem_cache_create+0x54/0x600 with crng_init=0 [ \
> 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000]
> ^^^^^^
>
> Without any concurrent atomic updates, the "broken" atomic accesses won't
> matter, I guess.

At least from my perspective, the machines that matter for hobbyists are uni-processors,
i.e. workstations. I don't know of any early Alpha workstations from the tip of my head
that are multi-processor.

Adrian

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

2024-05-13 16:11:42

by Linus Torvalds

[permalink] [raw]

Subject: Re: [GIT PULL] asm-generic cleanups for 6.10

On Fri, 10 May 2024 at 14:17, Arnd Bergmann <[email protected]> wrote:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git asm-generic-6.10

Hmm. That tag doesn't exist. The top commit you mention doesn't exist
under any other name either, so there isn't even a matching branch.

Linus

2024-05-13 16:27:55

by Linus Torvalds

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

On Fri, 10 May 2024 at 14:20, Arnd Bergmann <[email protected]> wrote:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git tags/asm-generic-alpha

Well, despite the discussion about timing of this, I have pulled this.
I still have a fond spot for alpha, even if it has the worst memory
ordering ever devised, but the lack of byte operations was an
inexcusable "we can deal with that in the compiler" senior moment in
the design. So good riddance.

Linus

2024-05-13 16:37:46

[permalink] [raw]

Subject: Re: [GIT PULL] asm-generic cleanups for 6.10

On Mon, May 13, 2024, at 16:11, Linus Torvalds wrote:
> On Fri, 10 May 2024 at 14:17, Arnd Bergmann <[email protected]> wrote:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git asm-generic-6.10
>
> Hmm. That tag doesn't exist. The top commit you mention doesn't exist
> under any other name either, so there isn't even a matching branch.

Indeed, I must have forgotten to push out the tag. Unfortunately
I'm traveling at the moment without my gpg key, and won't be
able to upload it until Friday. The contents are of course in
the for-next branch of the above tree (along with the other tag),
but they can all wait as they are all just cleanups that nothing
depends on for the moment.

At least it wasn't the arm-soc branches that I forgot to push,
that would have been more annoying.

Arnd

2024-05-13 17:06:13

by pr-tracker-bot

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

The pull request you sent on Fri, 10 May 2024 23:19:56 +0200:

> https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git tags/asm-generic-alpha

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/736676f5c3abd1fc01c41813a95246e892937f6d

Thank you!

--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

2024-05-13 17:36:23

by Ulrich Teichert

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

Hi,

> On Sun, 12 May 2024 07:44:25 -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.
> >
> > So why didn't the people running current mainline on pre-EV56 Alpha
> > systems notice? One possibility is that they are upgrading their
> > kernels only occasionally. Another possibility is that they are seeing
> > the failures, but are not tracing the obtuse failure modes back to the
> > change(s) in question. Yet another possibility is that the resulting
> > failures are very low probability, with mean times to failure that are
> > so long that you won't notice anything on a single system.
>
> Another possibility is that the Jensen system was booted into uni processer
> mode. Looking at the early boot log [1] provided by Ulrich (+CCed) back in
> Sept. 2021, I see the following by running "grep -i cpu":
>
> >> > [1] https://marc.info/?l=linux-alpha&m=163265555616841&w=2
>
> [ 0.000000] Memory: 90256K/131072K available (8897K kernel code, 9499K rwdata, \
> 2704K rodata, 312K init, 437K bss, 40816K reserved, 0K cma-reserved) [ 0.000000] \
> random: get_random_u64 called from __kmem_cache_create+0x54/0x600 with crng_init=0 [ \
> 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000]
> ^^^^^^
>
> Without any concurrent atomic updates, the "broken" atomic accesses won't
> matter, I guess.

I've probably disabled SMP in my test kernel, the jensen is a single CPU
system. I never had the pleasure of owning an AlphaServer 2000 or 2100,
which (according to https://en.wikipedia.org/wiki/AlphaServer and
https://en.wikipedia.org/wiki/AlphaStation) are the only systems
with EV4/EV45/EV5 multi-CPU setups (apart from the Cray T3{DE}), so
the possibility of ever seeing an error concerning atomic concurrent
updates is quite low.

Anybody out there with an AlphaServer 2000/2100 willing to try ?-)

CU,
Uli
--
Dipl. Inf. Ulrich Teichert|e-mail: [email protected] | Listening to:
Stormweg 24 |The Hives: Two Kinds Of Trouble, The Chats: 6L GTR,
24539 Neumuenster, Germany|La Fraction: Les Démons, Nightwatchers: On a Mission

2024-05-13 21:42:52

[permalink] [raw]

Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10

On Mon, 2024-05-13 at 09:27 -0700, Linus Torvalds wrote:
> On Fri, 10 May 2024 at 14:20, Arnd Bergmann <[email protected]> wrote:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git tags/asm-generic-alpha
>
> Well, despite the discussion about timing of this, I have pulled this.
> I still have a fond spot for alpha, even if it has the worst memory
> ordering ever devised, but the lack of byte operations was an
> inexcusable "we can deal with that in the compiler" senior moment in
> the design. So good riddance.

As someone who spends a lot of personal time and energy and even money into
Linux, I have to say the way this change was steamrolled into the kernel
without any real discussion actually hurts.

It's days like these when I'm starting to question my efforts.

Adrian

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

2024-05-13 21:44:23