* [GIT PULL] asm-generic cleanups for 6.10
@ 2024-05-10 21:17 Arnd Bergmann
2024-05-10 21:19 ` [GIT PULL] alpha: cleanups and build fixes " Arnd Bergmann
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Arnd Bergmann @ 2024-05-10 21:17 UTC (permalink / raw
To: Linus Torvalds; +Cc: linux-kernel, Linux-Arch, Thomas Zimmermann, Thorsten Blum
The following changes since commit e67572cd2204894179d89bd7b984072f19313b03:
Linux 6.9-rc6 (2024-04-28 13:47:24 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git asm-generic-6.10
for you to fetch changes up to e7cda7fe37ff1ece39bd2bf35ea68b1175395d95:
bug: Improve comment (2024-05-07 14:20:48 +0200)
----------------------------------------------------------------
asm-generic cleanups for 6.10
These are a few cross-architecture cleanup patches:
- Thomas Zimmermann works on separating fbdev support from the asm/video.h
contents that may be used by either the old fbdev drivers or the
newer drm display code.
- Thorsten Blum contributes cleanups for the generic bitops code
and asm-generic/bug.h
- I remove the orphaned include/asm-generic/page.h header that used to
included by long-removed mmu-less architectures.
----------------------------------------------------------------
Arnd Bergmann (1):
asm-generic: remove unused asm-generic/page.h
Thomas Zimmermann (3):
arch: Select fbdev helpers with CONFIG_VIDEO
arch: Remove struct fb_info from video helpers
arch: Rename fbdev header and source files
Thorsten Blum (2):
bitops: Change function return types from long to int
bug: Improve comment
arch/arc/include/asm/fb.h | 8 ---
arch/arm/include/asm/fb.h | 6 --
arch/arm64/include/asm/fb.h | 10 ---
arch/loongarch/include/asm/{fb.h => video.h} | 8 +--
arch/m68k/include/asm/{fb.h => video.h} | 8 +--
arch/mips/include/asm/{fb.h => video.h} | 12 ++--
arch/parisc/Makefile | 2 +-
arch/parisc/include/asm/fb.h | 14 ----
arch/parisc/include/asm/video.h | 16 +++++
arch/parisc/video/Makefile | 2 +-
arch/parisc/video/{fbdev.c => video-sti.c} | 9 +--
arch/powerpc/include/asm/{fb.h => video.h} | 8 +--
arch/powerpc/kernel/pci-common.c | 2 +-
arch/sh/include/asm/fb.h | 7 --
arch/sparc/Makefile | 4 +-
arch/sparc/include/asm/{fb.h => video.h} | 15 ++--
arch/sparc/video/Makefile | 2 +-
arch/sparc/video/fbdev.c | 26 -------
arch/sparc/video/video.c | 25 +++++++
arch/um/include/asm/Kbuild | 2 +-
arch/x86/Makefile | 2 +-
arch/x86/include/asm/fb.h | 19 -----
arch/x86/include/asm/video.h | 21 ++++++
arch/x86/video/Makefile | 3 +-
arch/x86/video/{fbdev.c => video.c} | 21 +++---
drivers/video/fbdev/core/fbcon.c | 2 +-
include/asm-generic/Kbuild | 2 +-
include/asm-generic/bitops/__ffs.h | 4 +-
include/asm-generic/bitops/__fls.h | 4 +-
include/asm-generic/bitops/builtin-__ffs.h | 2 +-
include/asm-generic/bitops/builtin-__fls.h | 2 +-
include/asm-generic/bug.h | 2 +-
include/asm-generic/page.h | 103 ---------------------------
include/asm-generic/{fb.h => video.h} | 17 ++---
include/linux/bitops.h | 6 +-
include/linux/fb.h | 2 +-
tools/include/asm-generic/bitops/__ffs.h | 4 +-
tools/include/asm-generic/bitops/__fls.h | 4 +-
tools/include/linux/bitops.h | 2 +-
39 files changed, 139 insertions(+), 269 deletions(-)
delete mode 100644 arch/arc/include/asm/fb.h
delete mode 100644 arch/arm/include/asm/fb.h
delete mode 100644 arch/arm64/include/asm/fb.h
rename arch/loongarch/include/asm/{fb.h => video.h} (86%)
rename arch/m68k/include/asm/{fb.h => video.h} (86%)
rename arch/mips/include/asm/{fb.h => video.h} (76%)
delete mode 100644 arch/parisc/include/asm/fb.h
create mode 100644 arch/parisc/include/asm/video.h
rename arch/parisc/video/{fbdev.c => video-sti.c} (78%)
rename arch/powerpc/include/asm/{fb.h => video.h} (76%)
delete mode 100644 arch/sh/include/asm/fb.h
rename arch/sparc/include/asm/{fb.h => video.h} (75%)
delete mode 100644 arch/sparc/video/fbdev.c
create mode 100644 arch/sparc/video/video.c
delete mode 100644 arch/x86/include/asm/fb.h
create mode 100644 arch/x86/include/asm/video.h
rename arch/x86/video/{fbdev.c => video.c} (66%)
delete mode 100644 include/asm-generic/page.h
rename include/asm-generic/{fb.h => video.h} (89%)
^ permalink raw reply [flat|nested] 25+ messages in thread
* [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-10 21:17 [GIT PULL] asm-generic cleanups for 6.10 Arnd Bergmann
@ 2024-05-10 21:19 ` Arnd Bergmann
2024-05-10 21:40 ` John Paul Adrian Glaubitz
` (3 more replies)
2024-05-13 16:11 ` [GIT PULL] asm-generic cleanups " Linus Torvalds
2024-05-20 22:35 ` pr-tracker-bot
2 siblings, 4 replies; 25+ messages in thread
From: Arnd Bergmann @ 2024-05-10 21:19 UTC (permalink / raw
To: Linus Torvalds
Cc: linux-kernel, Linux-Arch, linux-alpha, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Alexander Viro, Paul E. McKenney
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-10 21:19 ` [GIT PULL] alpha: cleanups and build fixes " Arnd Bergmann
@ 2024-05-10 21:40 ` John Paul Adrian Glaubitz
2024-05-10 22:28 ` Paul E. McKenney
2024-05-12 6:17 ` John Paul Adrian Glaubitz
` (2 subsequent siblings)
3 siblings, 1 reply; 25+ messages in thread
From: John Paul Adrian Glaubitz @ 2024-05-10 21:40 UTC (permalink / raw
To: Arnd Bergmann, Linus Torvalds
Cc: linux-kernel, Linux-Arch, linux-alpha, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Alexander Viro, Paul E. McKenney
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-10 21:40 ` John Paul Adrian Glaubitz
@ 2024-05-10 22:28 ` Paul E. McKenney
2024-05-11 18:49 ` John Paul Adrian Glaubitz
0 siblings, 1 reply; 25+ messages in thread
From: Paul E. McKenney @ 2024-05-10 22:28 UTC (permalink / raw
To: John Paul Adrian Glaubitz
Cc: Arnd Bergmann, Linus Torvalds, linux-kernel, Linux-Arch,
linux-alpha, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Alexander Viro
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-10 22:28 ` Paul E. McKenney
@ 2024-05-11 18:49 ` John Paul Adrian Glaubitz
2024-05-11 19:37 ` Paul E. McKenney
0 siblings, 1 reply; 25+ messages in thread
From: John Paul Adrian Glaubitz @ 2024-05-11 18:49 UTC (permalink / raw
To: paulmck
Cc: Arnd Bergmann, Linus Torvalds, linux-kernel, Linux-Arch,
linux-alpha, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Alexander Viro
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-11 18:49 ` John Paul Adrian Glaubitz
@ 2024-05-11 19:37 ` Paul E. McKenney
2024-05-11 20:08 ` Arnd Bergmann
0 siblings, 1 reply; 25+ messages in thread
From: Paul E. McKenney @ 2024-05-11 19:37 UTC (permalink / raw
To: John Paul Adrian Glaubitz
Cc: Arnd Bergmann, Linus Torvalds, linux-kernel, Linux-Arch,
linux-alpha, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Alexander Viro
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;
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-11 19:37 ` Paul E. McKenney
@ 2024-05-11 20:08 ` Arnd Bergmann
2024-05-12 1:26 ` Paul E. McKenney
0 siblings, 1 reply; 25+ messages in thread
From: Arnd Bergmann @ 2024-05-11 20:08 UTC (permalink / raw
To: Paul E. McKenney, John Paul Adrian Glaubitz
Cc: Linus Torvalds, linux-kernel, Linux-Arch, linux-alpha,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Alexander Viro
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-11 20:08 ` Arnd Bergmann
@ 2024-05-12 1:26 ` Paul E. McKenney
2024-05-12 6:02 ` John Paul Adrian Glaubitz
0 siblings, 1 reply; 25+ messages in thread
From: Paul E. McKenney @ 2024-05-12 1:26 UTC (permalink / raw
To: Arnd Bergmann
Cc: John Paul Adrian Glaubitz, Linus Torvalds, linux-kernel,
Linux-Arch, linux-alpha, Richard Henderson, Ivan Kokshaysky,
Matt Turner, Alexander Viro
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-12 1:26 ` Paul E. McKenney
@ 2024-05-12 6:02 ` John Paul Adrian Glaubitz
2024-05-12 14:44 ` Paul E. McKenney
0 siblings, 1 reply; 25+ messages in thread
From: John Paul Adrian Glaubitz @ 2024-05-12 6:02 UTC (permalink / raw
To: paulmck, Arnd Bergmann
Cc: Linus Torvalds, linux-kernel, Linux-Arch, linux-alpha,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Alexander Viro
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-10 21:19 ` [GIT PULL] alpha: cleanups and build fixes " Arnd Bergmann
2024-05-10 21:40 ` John Paul Adrian Glaubitz
@ 2024-05-12 6:17 ` John Paul Adrian Glaubitz
2024-05-13 16:27 ` Linus Torvalds
2024-05-13 17:05 ` pr-tracker-bot
3 siblings, 0 replies; 25+ messages in thread
From: John Paul Adrian Glaubitz @ 2024-05-12 6:17 UTC (permalink / raw
To: Arnd Bergmann, Linus Torvalds
Cc: Ulrich Teichert, debian-alpha, linux-kernel, Linux-Arch,
linux-alpha, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Alexander Viro, Paul E. McKenney
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-12 6:02 ` John Paul Adrian Glaubitz
@ 2024-05-12 14:44 ` Paul E. McKenney
2024-05-13 3:50 ` Akira Yokosawa
2024-05-13 7:10 ` John Paul Adrian Glaubitz
0 siblings, 2 replies; 25+ messages in thread
From: Paul E. McKenney @ 2024-05-12 14:44 UTC (permalink / raw
To: John Paul Adrian Glaubitz
Cc: Arnd Bergmann, Linus Torvalds, linux-kernel, Linux-Arch,
linux-alpha, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Alexander Viro
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-12 14:44 ` Paul E. McKenney
@ 2024-05-13 3:50 ` Akira Yokosawa
2024-05-13 4:03 ` Paul E. McKenney
` (2 more replies)
2024-05-13 7:10 ` John Paul Adrian Glaubitz
1 sibling, 3 replies; 25+ messages in thread
From: Akira Yokosawa @ 2024-05-13 3:50 UTC (permalink / raw
To: paulmck
Cc: arnd, glaubitz, ink, linux-alpha, linux-arch, linux-kernel,
mattst88, richard.henderson, torvalds, viro, Ulrich Teichert,
Akira Yokosawa
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-13 3:50 ` Akira Yokosawa
@ 2024-05-13 4:03 ` Paul E. McKenney
2024-05-13 6:28 ` Arnd Bergmann
2024-05-13 9:26 ` John Paul Adrian Glaubitz
2024-05-13 16:52 ` Ulrich Teichert
2 siblings, 1 reply; 25+ messages in thread
From: Paul E. McKenney @ 2024-05-13 4:03 UTC (permalink / raw
To: Akira Yokosawa
Cc: arnd, glaubitz, ink, linux-alpha, linux-arch, linux-kernel,
mattst88, richard.henderson, torvalds, viro, Ulrich Teichert
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-13 4:03 ` Paul E. McKenney
@ 2024-05-13 6:28 ` Arnd Bergmann
0 siblings, 0 replies; 25+ messages in thread
From: Arnd Bergmann @ 2024-05-13 6:28 UTC (permalink / raw
To: Paul E. McKenney, Akira Yokosawa
Cc: John Paul Adrian Glaubitz, Ivan Kokshaysky, linux-alpha,
Linux-Arch, linux-kernel, Matt Turner, Richard Henderson,
Linus Torvalds, Alexander Viro, Ulrich Teichert
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-12 14:44 ` Paul E. McKenney
2024-05-13 3:50 ` Akira Yokosawa
@ 2024-05-13 7:10 ` John Paul Adrian Glaubitz
1 sibling, 0 replies; 25+ messages in thread
From: John Paul Adrian Glaubitz @ 2024-05-13 7:10 UTC (permalink / raw
To: paulmck
Cc: Arnd Bergmann, Linus Torvalds, linux-kernel, Linux-Arch,
linux-alpha, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Alexander Viro
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-13 3:50 ` Akira Yokosawa
2024-05-13 4:03 ` Paul E. McKenney
@ 2024-05-13 9:26 ` John Paul Adrian Glaubitz
2024-05-13 16:52 ` Ulrich Teichert
2 siblings, 0 replies; 25+ messages in thread
From: John Paul Adrian Glaubitz @ 2024-05-13 9:26 UTC (permalink / raw
To: Akira Yokosawa, paulmck
Cc: arnd, ink, linux-alpha, linux-arch, linux-kernel, mattst88,
richard.henderson, torvalds, viro, Ulrich Teichert
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] asm-generic cleanups for 6.10
2024-05-10 21:17 [GIT PULL] asm-generic cleanups for 6.10 Arnd Bergmann
2024-05-10 21:19 ` [GIT PULL] alpha: cleanups and build fixes " Arnd Bergmann
@ 2024-05-13 16:11 ` Linus Torvalds
2024-05-13 16:36 ` Arnd Bergmann
2024-05-20 22:35 ` pr-tracker-bot
2 siblings, 1 reply; 25+ messages in thread
From: Linus Torvalds @ 2024-05-13 16:11 UTC (permalink / raw
To: Arnd Bergmann; +Cc: linux-kernel, Linux-Arch, Thomas Zimmermann, Thorsten Blum
On Fri, 10 May 2024 at 14:17, Arnd Bergmann <arnd@arndb.de> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-10 21:19 ` [GIT PULL] alpha: cleanups and build fixes " Arnd Bergmann
2024-05-10 21:40 ` John Paul Adrian Glaubitz
2024-05-12 6:17 ` John Paul Adrian Glaubitz
@ 2024-05-13 16:27 ` Linus Torvalds
2024-05-13 21:42 ` John Paul Adrian Glaubitz
2024-05-13 17:05 ` pr-tracker-bot
3 siblings, 1 reply; 25+ messages in thread
From: Linus Torvalds @ 2024-05-13 16:27 UTC (permalink / raw
To: Arnd Bergmann
Cc: linux-kernel, Linux-Arch, linux-alpha, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Alexander Viro, Paul E. McKenney
On Fri, 10 May 2024 at 14:20, Arnd Bergmann <arnd@arndb.de> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] asm-generic cleanups for 6.10
2024-05-13 16:11 ` [GIT PULL] asm-generic cleanups " Linus Torvalds
@ 2024-05-13 16:36 ` Arnd Bergmann
0 siblings, 0 replies; 25+ messages in thread
From: Arnd Bergmann @ 2024-05-13 16:36 UTC (permalink / raw
To: Linus Torvalds; +Cc: linux-kernel, Linux-Arch, Thomas Zimmermann, Thorsten Blum
On Mon, May 13, 2024, at 16:11, Linus Torvalds wrote:
> On Fri, 10 May 2024 at 14:17, Arnd Bergmann <arnd@arndb.de> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-13 3:50 ` Akira Yokosawa
2024-05-13 4:03 ` Paul E. McKenney
2024-05-13 9:26 ` John Paul Adrian Glaubitz
@ 2024-05-13 16:52 ` Ulrich Teichert
2024-05-13 21:44 ` John Paul Adrian Glaubitz
2 siblings, 1 reply; 25+ messages in thread
From: Ulrich Teichert @ 2024-05-13 16:52 UTC (permalink / raw
To: Akira Yokosawa
Cc: paulmck, arnd, glaubitz, ink, linux-alpha, linux-arch,
linux-kernel, mattst88, richard.henderson, torvalds, viro,
Ulrich Teichert, Akira Yokosawa
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: Ulrich.Teichert@gmx.de | 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-10 21:19 ` [GIT PULL] alpha: cleanups and build fixes " Arnd Bergmann
` (2 preceding siblings ...)
2024-05-13 16:27 ` Linus Torvalds
@ 2024-05-13 17:05 ` pr-tracker-bot
3 siblings, 0 replies; 25+ messages in thread
From: pr-tracker-bot @ 2024-05-13 17:05 UTC (permalink / raw
To: Arnd Bergmann
Cc: Linus Torvalds, linux-kernel, Linux-Arch, linux-alpha,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Alexander Viro,
Paul E. McKenney
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-13 16:27 ` Linus Torvalds
@ 2024-05-13 21:42 ` John Paul Adrian Glaubitz
2024-05-31 2:53 ` Maciej W. Rozycki
0 siblings, 1 reply; 25+ messages in thread
From: John Paul Adrian Glaubitz @ 2024-05-13 21:42 UTC (permalink / raw
To: Linus Torvalds, Arnd Bergmann
Cc: linux-kernel, Linux-Arch, linux-alpha, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Alexander Viro, Paul E. McKenney
On Mon, 2024-05-13 at 09:27 -0700, Linus Torvalds wrote:
> On Fri, 10 May 2024 at 14:20, Arnd Bergmann <arnd@arndb.de> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-13 16:52 ` Ulrich Teichert
@ 2024-05-13 21:44 ` John Paul Adrian Glaubitz
0 siblings, 0 replies; 25+ messages in thread
From: John Paul Adrian Glaubitz @ 2024-05-13 21:44 UTC (permalink / raw
To: Ulrich Teichert, Akira Yokosawa
Cc: paulmck, arnd, ink, linux-alpha, linux-arch, linux-kernel,
mattst88, richard.henderson, torvalds, viro
Hi Ulrich,
On Mon, 2024-05-13 at 18:52 +0200, Ulrich Teichert wrote:
> 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 ?-)
It has unfortunately been decided that further discussion is not wanted
and support for older Alpha hardware has now been removed. So there is
nothing more to try, unfortunately.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] asm-generic cleanups for 6.10
2024-05-10 21:17 [GIT PULL] asm-generic cleanups for 6.10 Arnd Bergmann
2024-05-10 21:19 ` [GIT PULL] alpha: cleanups and build fixes " Arnd Bergmann
2024-05-13 16:11 ` [GIT PULL] asm-generic cleanups " Linus Torvalds
@ 2024-05-20 22:35 ` pr-tracker-bot
2 siblings, 0 replies; 25+ messages in thread
From: pr-tracker-bot @ 2024-05-20 22:35 UTC (permalink / raw
To: Arnd Bergmann
Cc: Linus Torvalds, linux-kernel, Linux-Arch, Thomas Zimmermann,
Thorsten Blum
The pull request you sent on Fri, 10 May 2024 23:17:01 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git asm-generic-6.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/34cda5ab89d4f30bc8d8f8d28980a7b8c68db6ec
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
2024-05-13 21:42 ` John Paul Adrian Glaubitz
@ 2024-05-31 2:53 ` Maciej W. Rozycki
0 siblings, 0 replies; 25+ messages in thread
From: Maciej W. Rozycki @ 2024-05-31 2:53 UTC (permalink / raw
To: John Paul Adrian Glaubitz
Cc: Linus Torvalds, Arnd Bergmann, linux-kernel, Linux-Arch,
linux-alpha, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Alexander Viro, Paul E. McKenney
On Mon, 13 May 2024, John Paul Adrian Glaubitz wrote:
> > 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.
FWIW, me too (the other factor being recurring PSU failures). Sigh...
Maciej
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2024-05-31 2:53 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-05-10 21:17 [GIT PULL] asm-generic cleanups for 6.10 Arnd Bergmann
2024-05-10 21:19 ` [GIT PULL] alpha: cleanups and build fixes " Arnd Bergmann
2024-05-10 21:40 ` John Paul Adrian Glaubitz
2024-05-10 22:28 ` Paul E. McKenney
2024-05-11 18:49 ` John Paul Adrian Glaubitz
2024-05-11 19:37 ` Paul E. McKenney
2024-05-11 20:08 ` Arnd Bergmann
2024-05-12 1:26 ` Paul E. McKenney
2024-05-12 6:02 ` John Paul Adrian Glaubitz
2024-05-12 14:44 ` Paul E. McKenney
2024-05-13 3:50 ` Akira Yokosawa
2024-05-13 4:03 ` Paul E. McKenney
2024-05-13 6:28 ` Arnd Bergmann
2024-05-13 9:26 ` John Paul Adrian Glaubitz
2024-05-13 16:52 ` Ulrich Teichert
2024-05-13 21:44 ` John Paul Adrian Glaubitz
2024-05-13 7:10 ` John Paul Adrian Glaubitz
2024-05-12 6:17 ` John Paul Adrian Glaubitz
2024-05-13 16:27 ` Linus Torvalds
2024-05-13 21:42 ` John Paul Adrian Glaubitz
2024-05-31 2:53 ` Maciej W. Rozycki
2024-05-13 17:05 ` pr-tracker-bot
2024-05-13 16:11 ` [GIT PULL] asm-generic cleanups " Linus Torvalds
2024-05-13 16:36 ` Arnd Bergmann
2024-05-20 22:35 ` pr-tracker-bot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).