[GIT PULL] asm-generic cleanups for 6.10

[GIT PULL] asm-generic cleanups for 6.10

[Arnd Bergmann]

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%)

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

[Arnd Bergmann]

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

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

[John Paul Adrian Glaubitz]

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

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

[Paul E. McKenney]

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

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

[John Paul Adrian Glaubitz]

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

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

[Paul E. McKenney]

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;

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

[Arnd Bergmann]

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

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

[Paul E. McKenney]

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

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

[John Paul Adrian Glaubitz]

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

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

[Paul E. McKenney]

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

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

[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

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

[Paul E. McKenney]

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

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

[Arnd Bergmann]

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

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

[John Paul Adrian Glaubitz]

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

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

[Ulrich Teichert]

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

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

[John Paul Adrian Glaubitz]

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

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

[John Paul Adrian Glaubitz]

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

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

[John Paul Adrian Glaubitz]

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

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

[Linus Torvalds]

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

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

[John Paul Adrian Glaubitz]

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

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

[Maciej W. Rozycki]

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

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

[pr-tracker-bot]

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

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

[Linus Torvalds]

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

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

[Arnd Bergmann]

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

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

[pr-tracker-bot]

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