Fix accurate exception reporting in SPARC assembly

Fix accurate exception reporting in SPARC assembly

[Michael Karcher]

In 2018, David Miller implemented accurate exception reporting in
copy_from_user and copy_to_user by handling exceptions on each load
or store instruction that accesses userspace memory and calculating
the remaining bytes from the processor context. As issues with
transparent huge page support and folio support in ext4 were due
to a bogus return value from copy_from_user, I wrote a comprehensive
testsuite for the generic variant, and the machine-specific variants
for UltraSPARC I/II, UltraSPARC III, Niagara, Niagara 2/3 and
Niagara 4, see

https://github.com/karcherm/sparc-cfu-bug-reproducer

despite the name of the project, it does not only test copy_from_user,
but also copy_to_user, and it also contains fixes to a very small amount
of exception handler references that were calculating the result in
a wrong way.

For UltraSPARC III, I chose to adjust the memcpy code itself instead of
adding complexity to multiple exception handlers. That fix has already
been tested to fix stability issues observed by Adrian Glaubitz which
kicked of the investigation. On all other architectures, the changes
are just to the exception handlers.

Kind regards,
  Michael Karcher

[PATCH 1/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC

[Michael Karcher]

Fixes: cb736fdbb208 ("sparc64: Convert U1copy_{from,to}_user to accurate exception reporting.")
Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
---
 arch/sparc/lib/U1memcpy.S | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/sparc/lib/U1memcpy.S b/arch/sparc/lib/U1memcpy.S
index 635398ec7540..154fbd35400c 100644
--- a/arch/sparc/lib/U1memcpy.S
+++ b/arch/sparc/lib/U1memcpy.S
@@ -164,17 +164,18 @@ ENTRY(U1_gs_40_fp)
 	retl
 	 add		%o0, %o2, %o0
 ENDPROC(U1_gs_40_fp)
-ENTRY(U1_g3_0_fp)
-	VISExitHalf
-	retl
-	 add		%g3, %o2, %o0
-ENDPROC(U1_g3_0_fp)
 ENTRY(U1_g3_8_fp)
 	VISExitHalf
 	add		%g3, 8, %g3
 	retl
 	 add		%g3, %o2, %o0
 ENDPROC(U1_g3_8_fp)
+ENTRY(U1_g3_16_fp)
+	VISExitHalf
+	add		%g3, 16, %g3
+	retl
+	 add		%g3, %o2, %o0
+ENDPROC(U1_g3_16_fp)
 ENTRY(U1_o2_0_fp)
 	VISExitHalf
 	retl
@@ -547,18 +548,18 @@ FUNC_NAME:		/* %o0=dst, %o1=src, %o2=len */
 62:	FINISH_VISCHUNK(o0, f44, f46)
 63:	UNEVEN_VISCHUNK_LAST(o0, f46, f0)
 
-93:	EX_LD_FP(LOAD(ldd, %o1, %f2), U1_g3_0_fp)
+93:	EX_LD_FP(LOAD(ldd, %o1, %f2), U1_g3_8_fp)
 	add		%o1, 8, %o1
 	subcc		%g3, 8, %g3
 	faligndata	%f0, %f2, %f8
-	EX_ST_FP(STORE(std, %f8, %o0), U1_g3_8_fp)
+	EX_ST_FP(STORE(std, %f8, %o0), U1_g3_16_fp)
 	bl,pn		%xcc, 95f
 	 add		%o0, 8, %o0
-	EX_LD_FP(LOAD(ldd, %o1, %f0), U1_g3_0_fp)
+	EX_LD_FP(LOAD(ldd, %o1, %f0), U1_g3_8_fp)
 	add		%o1, 8, %o1
 	subcc		%g3, 8, %g3
 	faligndata	%f2, %f0, %f8
-	EX_ST_FP(STORE(std, %f8, %o0), U1_g3_8_fp)
+	EX_ST_FP(STORE(std, %f8, %o0), U1_g3_16_fp)
 	bge,pt		%xcc, 93b
 	 add		%o0, 8, %o0
 
-- 
2.50.1

Re: [PATCH 1/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC

[John Paul Adrian Glaubitz]

Hello,

On Tue, 2025-08-26 at 18:03 +0200, Michael Karcher wrote:
> Fixes: cb736fdbb208 ("sparc64: Convert U1copy_{from,to}_user to accurate exception reporting.")
> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> ---
>  arch/sparc/lib/U1memcpy.S | 19 ++++++++++---------
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/sparc/lib/U1memcpy.S b/arch/sparc/lib/U1memcpy.S
> index 635398ec7540..154fbd35400c 100644
> --- a/arch/sparc/lib/U1memcpy.S
> +++ b/arch/sparc/lib/U1memcpy.S
> @@ -164,17 +164,18 @@ ENTRY(U1_gs_40_fp)
>  	retl
>  	 add		%o0, %o2, %o0
>  ENDPROC(U1_gs_40_fp)
> -ENTRY(U1_g3_0_fp)
> -	VISExitHalf
> -	retl
> -	 add		%g3, %o2, %o0
> -ENDPROC(U1_g3_0_fp)
>  ENTRY(U1_g3_8_fp)
>  	VISExitHalf
>  	add		%g3, 8, %g3
>  	retl
>  	 add		%g3, %o2, %o0
>  ENDPROC(U1_g3_8_fp)
> +ENTRY(U1_g3_16_fp)
> +	VISExitHalf
> +	add		%g3, 16, %g3
> +	retl
> +	 add		%g3, %o2, %o0
> +ENDPROC(U1_g3_16_fp)
>  ENTRY(U1_o2_0_fp)
>  	VISExitHalf
>  	retl
> @@ -547,18 +548,18 @@ FUNC_NAME:		/* %o0=dst, %o1=src, %o2=len */
>  62:	FINISH_VISCHUNK(o0, f44, f46)
>  63:	UNEVEN_VISCHUNK_LAST(o0, f46, f0)
>  
> -93:	EX_LD_FP(LOAD(ldd, %o1, %f2), U1_g3_0_fp)
> +93:	EX_LD_FP(LOAD(ldd, %o1, %f2), U1_g3_8_fp)
>  	add		%o1, 8, %o1
>  	subcc		%g3, 8, %g3
>  	faligndata	%f0, %f2, %f8
> -	EX_ST_FP(STORE(std, %f8, %o0), U1_g3_8_fp)
> +	EX_ST_FP(STORE(std, %f8, %o0), U1_g3_16_fp)
>  	bl,pn		%xcc, 95f
>  	 add		%o0, 8, %o0
> -	EX_LD_FP(LOAD(ldd, %o1, %f0), U1_g3_0_fp)
> +	EX_LD_FP(LOAD(ldd, %o1, %f0), U1_g3_8_fp)
>  	add		%o1, 8, %o1
>  	subcc		%g3, 8, %g3
>  	faligndata	%f2, %f0, %f8
> -	EX_ST_FP(STORE(std, %f8, %o0), U1_g3_8_fp)
> +	EX_ST_FP(STORE(std, %f8, %o0), U1_g3_16_fp)
>  	bge,pt		%xcc, 93b
>  	 add		%o0, 8, %o0
>  

Verified to work on QEMU which emulates an UltraSPARC II:

root@debian:~# cat /proc/cpuinfo 
cpu             : TI UltraSparc IIi (Sabre)
fpu             : UltraSparc IIi integrated FPU
pmu             : ultra12
prom            : OBP 3.10.24 1999/01/01 01:01
type            : sun4u
ncpus probed    : 1
ncpus active    : 1
D$ parity tl1   : 0
I$ parity tl1   : 0
cpucaps         : flush,stbar,swap,muldiv,v9,mul32,div32,v8plus,vis
Cpu0ClkTck      : 0000000005f5e100
MMU Type        : Spitfire
MMU PGSZs       : 8K,64K,512K,4MB
State:
CPU0:           online
root@debian:~# 

While there were no obvious problems on UltraSPARC before, these may show after several
days of uptime, similar to Niagara 4. I remember though that there were user reports of
unstable kernels on real UltraSPARC I and II machines.

Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Adrian

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

Re: [PATCH 1/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC

[Rene Rebe]

Hi Michael, Adrian,

thank you so much for doing this work and dropping me a note to test!
I had bisected that last year, too, but due to lack of further time
only ended up reverting d563d678aa0 "fs: Handle intra-page faults in
copy_mount_options()". I also did not suspect copy_{from,to}_user be
that regressed and broken on sparc64, ... :-/

Tested-by: René Rebe <rene@exactcode.com> # on Ultra 5 UltraSparc IIi

> Fixes: cb736fdbb208 ("sparc64: Convert U1copy_{from,to}_user to accurate exception reporting.")
> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> ---
>  arch/sparc/lib/U1memcpy.S | 19 ++++++++++---------
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/sparc/lib/U1memcpy.S b/arch/sparc/lib/U1memcpy.S
> index 635398ec7540..154fbd35400c 100644
> --- a/arch/sparc/lib/U1memcpy.S
> +++ b/arch/sparc/lib/U1memcpy.S
> @@ -164,17 +164,18 @@ ENTRY(U1_gs_40_fp)
>  	retl
>  	 add		%o0, %o2, %o0
>  ENDPROC(U1_gs_40_fp)
> -ENTRY(U1_g3_0_fp)
> -	VISExitHalf
> -	retl
> -	 add		%g3, %o2, %o0
> -ENDPROC(U1_g3_0_fp)
>  ENTRY(U1_g3_8_fp)
>  	VISExitHalf
>  	add		%g3, 8, %g3
>  	retl
>  	 add		%g3, %o2, %o0
>  ENDPROC(U1_g3_8_fp)
> +ENTRY(U1_g3_16_fp)
> +	VISExitHalf
> +	add		%g3, 16, %g3
> +	retl
> +	 add		%g3, %o2, %o0
> +ENDPROC(U1_g3_16_fp)
>  ENTRY(U1_o2_0_fp)
>  	VISExitHalf
>  	retl
> @@ -547,18 +548,18 @@ FUNC_NAME:		/* %o0=dst, %o1=src, %o2=len */
>  62:	FINISH_VISCHUNK(o0, f44, f46)
>  63:	UNEVEN_VISCHUNK_LAST(o0, f46, f0)
>  
> -93:	EX_LD_FP(LOAD(ldd, %o1, %f2), U1_g3_0_fp)
> +93:	EX_LD_FP(LOAD(ldd, %o1, %f2), U1_g3_8_fp)
>  	add		%o1, 8, %o1
>  	subcc		%g3, 8, %g3
>  	faligndata	%f0, %f2, %f8
> -	EX_ST_FP(STORE(std, %f8, %o0), U1_g3_8_fp)
> +	EX_ST_FP(STORE(std, %f8, %o0), U1_g3_16_fp)
>  	bl,pn		%xcc, 95f
>  	 add		%o0, 8, %o0
> -	EX_LD_FP(LOAD(ldd, %o1, %f0), U1_g3_0_fp)
> +	EX_LD_FP(LOAD(ldd, %o1, %f0), U1_g3_8_fp)
>  	add		%o1, 8, %o1
>  	subcc		%g3, 8, %g3
>  	faligndata	%f2, %f0, %f8
> -	EX_ST_FP(STORE(std, %f8, %o0), U1_g3_8_fp)
> +	EX_ST_FP(STORE(std, %f8, %o0), U1_g3_16_fp)
>  	bge,pt		%xcc, 93b
>  	 add		%o0, 8, %o0
>  
> -- 
> 2.50.1
> 
> 

-- 
  René Rebe, ExactCODE GmbH, Berlin, Germany.
  https://exactcode.com | https://t2linux.com | https://rene.rebe.de

[PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III

[Michael Karcher]

Based on a finding by Anthony Yznaga that the UltraSPARC III copy_from_user
returns invalid values breaking other parts of the kernel in case of a
fault, while the generic implementation is correct.

Fixes: ee841d0aff64 ("sparc64: Convert U3copy_{from,to}_user to accurate exception reporting.")
Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
---
 arch/sparc/lib/U3memcpy.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sparc/lib/U3memcpy.S b/arch/sparc/lib/U3memcpy.S
index 9248d59c734c..bace3a18f836 100644
--- a/arch/sparc/lib/U3memcpy.S
+++ b/arch/sparc/lib/U3memcpy.S
@@ -267,6 +267,7 @@ FUNC_NAME:	/* %o0=dst, %o1=src, %o2=len */
 	faligndata	%f10, %f12, %f26
 	EX_LD_FP(LOAD(ldd, %o1 + 0x040, %f0), U3_retl_o2)
 
+	and		%o2, 0x3f, %o2
 	subcc		GLOBAL_SPARE, 0x80, GLOBAL_SPARE
 	add		%o1, 0x40, %o1
 	bgu,pt		%XCC, 1f
@@ -336,7 +337,6 @@ FUNC_NAME:	/* %o0=dst, %o1=src, %o2=len */
 	 * Also notice how this code is careful not to perform a
 	 * load past the end of the src buffer.
 	 */
-	and		%o2, 0x3f, %o2
 	andcc		%o2, 0x38, %g2
 	be,pn		%XCC, 2f
 	 subcc		%g2, 0x8, %g2
-- 
2.50.1

Re: [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III

[John Paul Adrian Glaubitz]

Hi Michael,

On Tue, 2025-08-26 at 18:03 +0200, Michael Karcher wrote:
> Based on a finding by Anthony Yznaga that the UltraSPARC III copy_from_user
> returns invalid values breaking other parts of the kernel in case of a
> fault, while the generic implementation is correct.
> 
> Fixes: ee841d0aff64 ("sparc64: Convert U3copy_{from,to}_user to accurate exception reporting.")
> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> ---
>  arch/sparc/lib/U3memcpy.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/sparc/lib/U3memcpy.S b/arch/sparc/lib/U3memcpy.S
> index 9248d59c734c..bace3a18f836 100644
> --- a/arch/sparc/lib/U3memcpy.S
> +++ b/arch/sparc/lib/U3memcpy.S
> @@ -267,6 +267,7 @@ FUNC_NAME:	/* %o0=dst, %o1=src, %o2=len */
>  	faligndata	%f10, %f12, %f26
>  	EX_LD_FP(LOAD(ldd, %o1 + 0x040, %f0), U3_retl_o2)
>  
> +	and		%o2, 0x3f, %o2
>  	subcc		GLOBAL_SPARE, 0x80, GLOBAL_SPARE
>  	add		%o1, 0x40, %o1
>  	bgu,pt		%XCC, 1f
> @@ -336,7 +337,6 @@ FUNC_NAME:	/* %o0=dst, %o1=src, %o2=len */
>  	 * Also notice how this code is careful not to perform a
>  	 * load past the end of the src buffer.
>  	 */
> -	and		%o2, 0x3f, %o2
>  	andcc		%o2, 0x38, %g2
>  	be,pn		%XCC, 2f
>  	 subcc		%g2, 0x8, %g2

I patched Debian's unstable kernel yesterday and to my surprise, the kernel crashed
during boot on the Sun Netra 240. Could be related to some Debian-specific changes
though or to issues with gcc-14:

[   30.683477] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[   30.683485] rcu:     (detected by 0, t=5262 jiffies, g=-955, q=12 ncpus=1)
[   30.683492] rcu: All QSes seen, last rcu_sched kthread activity 5262 (4294897854-4294892592), jiffies_till_next_fqs=1, root ->qsmask 0x0
[   30.683503] rcu: rcu_sched kthread starved for 5262 jiffies! g-955 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
[   30.683511] rcu:     Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
[   30.683515] rcu: RCU grace-period kthread stack dump:
[   30.683518] task:rcu_sched       state:R  running task     stack:0     pid:15    tgid:15    ppid:2      task_flags:0x208040 flags:0x07000000
[   30.683536] Call Trace:
[   30.683540] [<0000000000f80a5c>] schedule+0x1c/0x180
[   30.683562] [<0000000000f870b0>] schedule_timeout+0x70/0x100
[   30.683572] [<000000000052b4c8>] rcu_gp_fqs_loop+0x108/0x5e0
[   30.683582] [<0000000000530ae0>] rcu_gp_kthread+0x180/0x200
[   30.683591] [<00000000004ac704>] kthread+0x104/0x280
[   30.683605] [<00000000004060c8>] ret_from_fork+0x1c/0x2c
[   30.683618] [<0000000000000000>] 0x0
[   30.683626] rcu: Stack dump where RCU GP kthread last ran:
[   30.683632] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.3+1-sparc64-smp #1 NONE  Debian 6.16.3-1+sparc64 
[   30.683642] TSTATE: 0000004411001602 TPC: 000000000050bbf0 TNPC: 000000000050bbf4 Y: 0000004a    Not tainted
[   30.683648] TPC: <console_flush_all+0x3d0/0x540>
[   30.683662] g0: 000000000050bbf0 g1: 0000000000000000 g2: 0000000000000000 g3: 0000000001544800
[   30.683668] g4: fff000000022ad00 g5: fff000023e2f6000 g6: fff0000000264000 g7: 000000000000000e
[   30.683673] o0: 0000000001544958 o1: 0000000001543d48 o2: 000000000000004f o3: 00000000015b3080
[   30.683678] o4: 00000000015b3080 o5: 00000000015b3080 sp: fff00000002663f1 ret_pc: 000000000050bbe0
[   30.683683] RPC: <console_flush_all+0x3c0/0x540>
[   30.683692] l0: 0000000001544958 l1: 0000000000000000 l2: 0000000001543d48 l3: 00000000012e3ef8
[   30.683697] l4: 00000000013fb770 l5: 0000000000000000 l6: 000000000137a800 l7: 000000000000004f
[   30.683702] i0: 0000000000000000 i1: fff0000000266db8 i2: fff0000000266db3 i3: 00000000012f65f0
[   30.683707] i4: 0000000000000000 i5: 00000000012f65f0 i6: fff0000000266501 i7: 000000000050bdf8
[   30.683712] I7: <console_unlock+0x98/0x140>
[   30.683721] Call Trace:
[   30.683724] [<000000000050bdf8>] console_unlock+0x98/0x140
[   30.683733] [<000000000050cbec>] vprintk_emit+0x2cc/0x360
[   30.683742] [<000000000050cc9c>] vprintk_default+0x1c/0x40
[   30.683752] [<000000000050dbd0>] vprintk+0x10/0x20
[   30.683761] [<000000000042b3a8>] _printk+0x24/0x34
[   30.683772] [<000000000050d1c8>] register_console+0x3a8/0x600
[   30.683781] [<0000000000bd07c0>] serial_core_register_port+0x680/0x8a0
[   30.683790] [<0000000000bd12f0>] serial_ctrl_register_port+0x10/0x20
[   30.683798] [<0000000000bd1370>] uart_add_one_port+0x10/0x20
[   30.683806] [<0000000000bd8bb4>] su_probe+0x174/0x400
[   30.683816] [<0000000000c044cc>] platform_probe+0x4c/0xc0
[   30.683825] [<0000000000c00e28>] really_probe+0xc8/0x400
[   30.683839] [<0000000000c011ec>] __driver_probe_device+0x8c/0x160
[   30.683848] [<0000000000c013a8>] driver_probe_device+0x28/0x100
[   30.683857] [<0000000000c0165c>] __driver_attach+0xbc/0x1e0
[   30.683865] [<0000000000bfe7dc>] bus_for_each_dev+0x5c/0xc0
[   32.641998] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper/0:1]
[   32.642006] Modules linked in:
[   32.642012] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.3+1-sparc64-smp #1 NONE  Debian 6.16.3-1+sparc64 
[   32.642020] TSTATE: 0000004411001602 TPC: 000000000050bbf0 TNPC: 000000000050bbf4 Y: 00000052    Not tainted
[   32.642026] TPC: <console_flush_all+0x3d0/0x540>
[   32.642035] g0: 00000000015b1f48 g1: 0000000000000000 g2: 0000000000000000 g3: 0000000001544800
[   32.642040] g4: fff000000022ad00 g5: fff000023e2f6000 g6: fff0000000264000 g7: 000000000000000e
[   32.642045] o0: 0000000001544958 o1: 0000000001543d48 o2: 0000000000000054 o3: 00000000015b3080
[   32.642050] o4: 00000000015b3080 o5: 00000000015b3080 sp: fff00000002663f1 ret_pc: 000000000050bbe0
[   32.642054] RPC: <console_flush_all+0x3c0/0x540>
[   32.642062] l0: 0000000001544958 l1: 0000000000000000 l2: 0000000001543d48 l3: 00000000012e3ef8
[   32.642067] l4: 00000000013fb770 l5: 0000000000000000 l6: 000000000137a800 l7: 0000000000000054
[   32.642072] i0: 0000000000000000 i1: fff0000000266db8 i2: fff0000000266db3 i3: 00000000012f65f0
[   32.642077] i4: 0000000000000000 i5: 00000000012f65f0 i6: fff0000000266501 i7: 000000000050bdf8
[   32.642081] I7: <console_unlock+0x98/0x140>
[   32.642089] Call Trace:
[   32.642092] [<000000000050bdf8>] console_unlock+0x98/0x140
[   32.642101] [<000000000050cbec>] vprintk_emit+0x2cc/0x360
[   32.642110] [<000000000050cc9c>] vprintk_default+0x1c/0x40
[   32.642118] [<000000000050dbd0>] vprintk+0x10/0x20
[   32.642127] [<000000000042b3a8>] _printk+0x24/0x34
[   32.642135] [<000000000050d1c8>] register_console+0x3a8/0x600
[   32.642144] [<0000000000bd07c0>] serial_core_register_port+0x680/0x8a0
[   32.642151] [<0000000000bd12f0>] serial_ctrl_register_port+0x10/0x20
[   32.642158] [<0000000000bd1370>] uart_add_one_port+0x10/0x20
[   32.642165] [<0000000000bd8bb4>] su_probe+0x174/0x400
[   32.642173] [<0000000000c044cc>] platform_probe+0x4c/0xc0
[   32.642180] [<0000000000c00e28>] really_probe+0xc8/0x400
[   32.642189] [<0000000000c011ec>] __driver_probe_device+0x8c/0x160
[   32.642198] [<0000000000c013a8>] driver_probe_device+0x28/0x100
[   32.642206] [<0000000000c0165c>] __driver_attach+0xbc/0x1e0
[   32.642215] [<0000000000bfe7dc>] bus_for_each_dev+0x5c/0xc0

Adrian

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

Re: [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III

[John Paul Adrian Glaubitz]

Hello,

On Tue, 2025-08-26 at 18:03 +0200, Michael Karcher wrote:
> Based on a finding by Anthony Yznaga that the UltraSPARC III copy_from_user
> returns invalid values breaking other parts of the kernel in case of a
> fault, while the generic implementation is correct.
> 
> Fixes: ee841d0aff64 ("sparc64: Convert U3copy_{from,to}_user to accurate exception reporting.")
> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> ---
>  arch/sparc/lib/U3memcpy.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/sparc/lib/U3memcpy.S b/arch/sparc/lib/U3memcpy.S
> index 9248d59c734c..bace3a18f836 100644
> --- a/arch/sparc/lib/U3memcpy.S
> +++ b/arch/sparc/lib/U3memcpy.S
> @@ -267,6 +267,7 @@ FUNC_NAME:	/* %o0=dst, %o1=src, %o2=len */
>  	faligndata	%f10, %f12, %f26
>  	EX_LD_FP(LOAD(ldd, %o1 + 0x040, %f0), U3_retl_o2)
>  
> +	and		%o2, 0x3f, %o2
>  	subcc		GLOBAL_SPARE, 0x80, GLOBAL_SPARE
>  	add		%o1, 0x40, %o1
>  	bgu,pt		%XCC, 1f
> @@ -336,7 +337,6 @@ FUNC_NAME:	/* %o0=dst, %o1=src, %o2=len */
>  	 * Also notice how this code is careful not to perform a
>  	 * load past the end of the src buffer.
>  	 */
> -	and		%o2, 0x3f, %o2
>  	andcc		%o2, 0x38, %g2
>  	be,pn		%XCC, 2f
>  	 subcc		%g2, 0x8, %g2

After further testing, it turned out that the previously observed crash was
related to my build environment. I can confirm that with the patch applied,
the previously observed memory corruptions on UltraSPARC III are fixed.

Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Adrian

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

Re: [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III

[Anthony Yznaga]

On 8/26/25 9:03 AM, Michael Karcher wrote:
> Based on a finding by Anthony Yznaga that the UltraSPARC III copy_from_user
> returns invalid values breaking other parts of the kernel in case of a
> fault, while the generic implementation is correct.

I think there should be a little more text about the nature of the 
failure. Maybe:

He observed that a BUG_ON in ext4 code with large folios enabled 
resulted from copy_from_user() returning impossibly large values greater 
than the size to be copied. This lead to __copy_from_iter() returning 
impossible values instead of the actual number of bytes it was able to copy.

Otherwise, the fix looks good.

Reviewed-by: Anthony Yznaga <anthony.yznaga@oracle.com>


> 
> Fixes: ee841d0aff64 ("sparc64: Convert U3copy_{from,to}_user to accurate exception reporting.")
> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> ---
>   arch/sparc/lib/U3memcpy.S | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/sparc/lib/U3memcpy.S b/arch/sparc/lib/U3memcpy.S
> index 9248d59c734c..bace3a18f836 100644
> --- a/arch/sparc/lib/U3memcpy.S
> +++ b/arch/sparc/lib/U3memcpy.S
> @@ -267,6 +267,7 @@ FUNC_NAME:	/* %o0=dst, %o1=src, %o2=len */
>   	faligndata	%f10, %f12, %f26
>   	EX_LD_FP(LOAD(ldd, %o1 + 0x040, %f0), U3_retl_o2)
>   
> +	and		%o2, 0x3f, %o2
>   	subcc		GLOBAL_SPARE, 0x80, GLOBAL_SPARE
>   	add		%o1, 0x40, %o1
>   	bgu,pt		%XCC, 1f
> @@ -336,7 +337,6 @@ FUNC_NAME:	/* %o0=dst, %o1=src, %o2=len */
>   	 * Also notice how this code is careful not to perform a
>   	 * load past the end of the src buffer.
>   	 */
> -	and		%o2, 0x3f, %o2
>   	andcc		%o2, 0x38, %g2
>   	be,pn		%XCC, 2f
>   	 subcc		%g2, 0x8, %g2

Re: [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III

[Michael Karcher]

>I think there should be a little more text about the nature of the failure. Maybe:

I will add something like that in v2 of the series.
Do you think it is useful to add the message ID
b14f55642207e63e907965e209f6323a0df6dcee.camel@physik.fu-berlin.de
as well, or an abbreviated backtrace from that message?
I suppose, that is the BUG_ON you are referring to.

>Otherwise, the fix looks good.
>
>Reviewed-by: Anthony Yznaga <anthony.yznaga@oracle.com>
Thanks.

Kind regards,
  Michael Karcher

Re: [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III

[Rene Rebe]

Hi,

From: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>

> Based on a finding by Anthony Yznaga that the UltraSPARC III copy_from_user
> returns invalid values breaking other parts of the kernel in case of a
> fault, while the generic implementation is correct.

Tested-by: René Rebe <rene@exactcode.com> # UltraSparc III+ and UltraSparc IIIi

> Fixes: ee841d0aff64 ("sparc64: Convert U3copy_{from,to}_user to accurate exception reporting.")
> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> ---
>  arch/sparc/lib/U3memcpy.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/sparc/lib/U3memcpy.S b/arch/sparc/lib/U3memcpy.S
> index 9248d59c734c..bace3a18f836 100644
> --- a/arch/sparc/lib/U3memcpy.S
> +++ b/arch/sparc/lib/U3memcpy.S
> @@ -267,6 +267,7 @@ FUNC_NAME:	/* %o0=dst, %o1=src, %o2=len */
>  	faligndata	%f10, %f12, %f26
>  	EX_LD_FP(LOAD(ldd, %o1 + 0x040, %f0), U3_retl_o2)
>  
> +	and		%o2, 0x3f, %o2
>  	subcc		GLOBAL_SPARE, 0x80, GLOBAL_SPARE
>  	add		%o1, 0x40, %o1
>  	bgu,pt		%XCC, 1f
> @@ -336,7 +337,6 @@ FUNC_NAME:	/* %o0=dst, %o1=src, %o2=len */
>  	 * Also notice how this code is careful not to perform a
>  	 * load past the end of the src buffer.
>  	 */
> -	and		%o2, 0x3f, %o2
>  	andcc		%o2, 0x38, %g2
>  	be,pn		%XCC, 2f
>  	 subcc		%g2, 0x8, %g2
> -- 
> 2.50.1
> 
> 

-- 
  René Rebe, ExactCODE GmbH, Berlin, Germany
  https://exactcode.com | https://t2linux.com | https://rene.rebe.de

[PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara

[Michael Karcher]

Fixes: 7ae3aaf53f16 ("sparc64: Convert NGcopy_{from,to}_user to accurate exception reporting.")
Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
---
 arch/sparc/lib/NGmemcpy.S | 29 ++++++++++++++++++-----------
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/arch/sparc/lib/NGmemcpy.S b/arch/sparc/lib/NGmemcpy.S
index ee51c1230689..bbd3ea0a6482 100644
--- a/arch/sparc/lib/NGmemcpy.S
+++ b/arch/sparc/lib/NGmemcpy.S
@@ -79,8 +79,8 @@
 #ifndef EX_RETVAL
 #define EX_RETVAL(x)	x
 __restore_asi:
-	ret
 	wr	%g0, ASI_AIUS, %asi
+	ret
 	 restore
 ENTRY(NG_ret_i2_plus_i4_plus_1)
 	ba,pt	%xcc, __restore_asi
@@ -125,15 +125,16 @@ ENTRY(NG_ret_i2_plus_g1_minus_56)
 	ba,pt	%xcc, __restore_asi
 	 add	%i2, %g1, %i0
 ENDPROC(NG_ret_i2_plus_g1_minus_56)
-ENTRY(NG_ret_i2_plus_i4)
+ENTRY(NG_ret_i2_plus_i4_plus_16)
+        add     %i4, 16, %i4
 	ba,pt	%xcc, __restore_asi
 	 add	%i2, %i4, %i0
-ENDPROC(NG_ret_i2_plus_i4)
-ENTRY(NG_ret_i2_plus_i4_minus_8)
-	sub	%i4, 8, %i4
+ENDPROC(NG_ret_i2_plus_i4_plus_16)
+ENTRY(NG_ret_i2_plus_i4_plus_8)
+	add	%i4, 8, %i4
 	ba,pt	%xcc, __restore_asi
 	 add	%i2, %i4, %i0
-ENDPROC(NG_ret_i2_plus_i4_minus_8)
+ENDPROC(NG_ret_i2_plus_i4_plus_8)
 ENTRY(NG_ret_i2_plus_8)
 	ba,pt	%xcc, __restore_asi
 	 add	%i2, 8, %i0
@@ -160,6 +161,12 @@ ENTRY(NG_ret_i2_and_7_plus_i4)
 	ba,pt	%xcc, __restore_asi
 	 add	%i2, %i4, %i0
 ENDPROC(NG_ret_i2_and_7_plus_i4)
+ENTRY(NG_ret_i2_and_7_plus_i4_plus_8)
+	and	%i2, 7, %i2
+	add	%i4, 8, %i4
+	ba,pt	%xcc, __restore_asi
+	 add	%i2, %i4, %i0
+ENDPROC(NG_ret_i2_and_7_plus_i4)
 #endif
 
 	.align		64
@@ -405,13 +412,13 @@ FUNC_NAME:	/* %i0=dst, %i1=src, %i2=len */
 	andn		%i2, 0xf, %i4
 	and		%i2, 0xf, %i2
 1:	subcc		%i4, 0x10, %i4
-	EX_LD(LOAD(ldx, %i1, %o4), NG_ret_i2_plus_i4)
+	EX_LD(LOAD(ldx, %i1, %o4), NG_ret_i2_plus_i4_plus_16)
 	add		%i1, 0x08, %i1
-	EX_LD(LOAD(ldx, %i1, %g1), NG_ret_i2_plus_i4)
+	EX_LD(LOAD(ldx, %i1, %g1), NG_ret_i2_plus_i4_plus_16)
 	sub		%i1, 0x08, %i1
-	EX_ST(STORE(stx, %o4, %i1 + %i3), NG_ret_i2_plus_i4)
+	EX_ST(STORE(stx, %o4, %i1 + %i3), NG_ret_i2_plus_i4_plus_16)
 	add		%i1, 0x8, %i1
-	EX_ST(STORE(stx, %g1, %i1 + %i3), NG_ret_i2_plus_i4_minus_8)
+	EX_ST(STORE(stx, %g1, %i1 + %i3), NG_ret_i2_plus_i4_plus_8)
 	bgu,pt		%XCC, 1b
 	 add		%i1, 0x8, %i1
 73:	andcc		%i2, 0x8, %g0
@@ -468,7 +475,7 @@ FUNC_NAME:	/* %i0=dst, %i1=src, %i2=len */
 	subcc		%i4, 0x8, %i4
 	srlx		%g3, %i3, %i5
 	or		%i5, %g2, %i5
-	EX_ST(STORE(stx, %i5, %o0), NG_ret_i2_and_7_plus_i4)
+	EX_ST(STORE(stx, %i5, %o0), NG_ret_i2_and_7_plus_i4_plus_8)
 	add		%o0, 0x8, %o0
 	bgu,pt		%icc, 1b
 	 sllx		%g3, %g1, %g2
-- 
2.50.1

Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara

[John Paul Adrian Glaubitz]

Hello,

On Tue, 2025-08-26 at 18:03 +0200, Michael Karcher wrote:
> Fixes: 7ae3aaf53f16 ("sparc64: Convert NGcopy_{from,to}_user to accurate exception reporting.")
> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> ---
>  arch/sparc/lib/NGmemcpy.S | 29 ++++++++++++++++++-----------
>  1 file changed, 18 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/sparc/lib/NGmemcpy.S b/arch/sparc/lib/NGmemcpy.S
> index ee51c1230689..bbd3ea0a6482 100644
> --- a/arch/sparc/lib/NGmemcpy.S
> +++ b/arch/sparc/lib/NGmemcpy.S
> @@ -79,8 +79,8 @@
>  #ifndef EX_RETVAL
>  #define EX_RETVAL(x)	x
>  __restore_asi:
> -	ret
>  	wr	%g0, ASI_AIUS, %asi
> +	ret
>  	 restore
>  ENTRY(NG_ret_i2_plus_i4_plus_1)
>  	ba,pt	%xcc, __restore_asi
> @@ -125,15 +125,16 @@ ENTRY(NG_ret_i2_plus_g1_minus_56)
>  	ba,pt	%xcc, __restore_asi
>  	 add	%i2, %g1, %i0
>  ENDPROC(NG_ret_i2_plus_g1_minus_56)
> -ENTRY(NG_ret_i2_plus_i4)
> +ENTRY(NG_ret_i2_plus_i4_plus_16)
> +        add     %i4, 16, %i4
>  	ba,pt	%xcc, __restore_asi
>  	 add	%i2, %i4, %i0
> -ENDPROC(NG_ret_i2_plus_i4)
> -ENTRY(NG_ret_i2_plus_i4_minus_8)
> -	sub	%i4, 8, %i4
> +ENDPROC(NG_ret_i2_plus_i4_plus_16)
> +ENTRY(NG_ret_i2_plus_i4_plus_8)
> +	add	%i4, 8, %i4
>  	ba,pt	%xcc, __restore_asi
>  	 add	%i2, %i4, %i0
> -ENDPROC(NG_ret_i2_plus_i4_minus_8)
> +ENDPROC(NG_ret_i2_plus_i4_plus_8)
>  ENTRY(NG_ret_i2_plus_8)
>  	ba,pt	%xcc, __restore_asi
>  	 add	%i2, 8, %i0
> @@ -160,6 +161,12 @@ ENTRY(NG_ret_i2_and_7_plus_i4)
>  	ba,pt	%xcc, __restore_asi
>  	 add	%i2, %i4, %i0
>  ENDPROC(NG_ret_i2_and_7_plus_i4)
> +ENTRY(NG_ret_i2_and_7_plus_i4_plus_8)
> +	and	%i2, 7, %i2
> +	add	%i4, 8, %i4
> +	ba,pt	%xcc, __restore_asi
> +	 add	%i2, %i4, %i0
> +ENDPROC(NG_ret_i2_and_7_plus_i4)
>  #endif
>  
>  	.align		64
> @@ -405,13 +412,13 @@ FUNC_NAME:	/* %i0=dst, %i1=src, %i2=len */
>  	andn		%i2, 0xf, %i4
>  	and		%i2, 0xf, %i2
>  1:	subcc		%i4, 0x10, %i4
> -	EX_LD(LOAD(ldx, %i1, %o4), NG_ret_i2_plus_i4)
> +	EX_LD(LOAD(ldx, %i1, %o4), NG_ret_i2_plus_i4_plus_16)
>  	add		%i1, 0x08, %i1
> -	EX_LD(LOAD(ldx, %i1, %g1), NG_ret_i2_plus_i4)
> +	EX_LD(LOAD(ldx, %i1, %g1), NG_ret_i2_plus_i4_plus_16)
>  	sub		%i1, 0x08, %i1
> -	EX_ST(STORE(stx, %o4, %i1 + %i3), NG_ret_i2_plus_i4)
> +	EX_ST(STORE(stx, %o4, %i1 + %i3), NG_ret_i2_plus_i4_plus_16)
>  	add		%i1, 0x8, %i1
> -	EX_ST(STORE(stx, %g1, %i1 + %i3), NG_ret_i2_plus_i4_minus_8)
> +	EX_ST(STORE(stx, %g1, %i1 + %i3), NG_ret_i2_plus_i4_plus_8)
>  	bgu,pt		%XCC, 1b
>  	 add		%i1, 0x8, %i1
>  73:	andcc		%i2, 0x8, %g0
> @@ -468,7 +475,7 @@ FUNC_NAME:	/* %i0=dst, %i1=src, %i2=len */
>  	subcc		%i4, 0x8, %i4
>  	srlx		%g3, %i3, %i5
>  	or		%i5, %g2, %i5
> -	EX_ST(STORE(stx, %i5, %o0), NG_ret_i2_and_7_plus_i4)
> +	EX_ST(STORE(stx, %i5, %o0), NG_ret_i2_and_7_plus_i4_plus_8)
>  	add		%o0, 0x8, %o0
>  	bgu,pt		%icc, 1b
>  	 sllx		%g3, %g1, %g2

Verified on a SPARC T4 with the following hack applied:

diff --git a/arch/sparc/kernel/head_64.S b/arch/sparc/kernel/head_64.S
index cf0549134234..886cb8932a0b 100644
--- a/arch/sparc/kernel/head_64.S
+++ b/arch/sparc/kernel/head_64.S
@@ -635,7 +635,7 @@ sparc_m7_patch:
         nop
 
 niagara4_patch:
-       call    niagara4_patch_copyops
+       call    niagara_patch_copyops
         nop
        call    niagara4_patch_bzero
         nop

Kernel is stable and does not produce any backtraces. Should still be
tested on a real SPARC T1 if possible though.

Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Adrian

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

Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara

[Rene Rebe]

Hi,

From: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>

> Fixes: 7ae3aaf53f16 ("sparc64: Convert NGcopy_{from,to}_user to accurate exception reporting.")
> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>

Tested-by: René Rebe <rene@exactcode.com> # UltraSparc T4 SPARC T4-1 Server

> ---
>  arch/sparc/lib/NGmemcpy.S | 29 ++++++++++++++++++-----------
>  1 file changed, 18 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/sparc/lib/NGmemcpy.S b/arch/sparc/lib/NGmemcpy.S
> index ee51c1230689..bbd3ea0a6482 100644
> --- a/arch/sparc/lib/NGmemcpy.S
> +++ b/arch/sparc/lib/NGmemcpy.S
> @@ -79,8 +79,8 @@
>  #ifndef EX_RETVAL
>  #define EX_RETVAL(x)	x
>  __restore_asi:
> -	ret
>  	wr	%g0, ASI_AIUS, %asi
> +	ret
>  	 restore
>  ENTRY(NG_ret_i2_plus_i4_plus_1)
>  	ba,pt	%xcc, __restore_asi
> @@ -125,15 +125,16 @@ ENTRY(NG_ret_i2_plus_g1_minus_56)
>  	ba,pt	%xcc, __restore_asi
>  	 add	%i2, %g1, %i0
>  ENDPROC(NG_ret_i2_plus_g1_minus_56)
> -ENTRY(NG_ret_i2_plus_i4)
> +ENTRY(NG_ret_i2_plus_i4_plus_16)
> +        add     %i4, 16, %i4
>  	ba,pt	%xcc, __restore_asi
>  	 add	%i2, %i4, %i0
> -ENDPROC(NG_ret_i2_plus_i4)
> -ENTRY(NG_ret_i2_plus_i4_minus_8)
> -	sub	%i4, 8, %i4
> +ENDPROC(NG_ret_i2_plus_i4_plus_16)
> +ENTRY(NG_ret_i2_plus_i4_plus_8)
> +	add	%i4, 8, %i4
>  	ba,pt	%xcc, __restore_asi
>  	 add	%i2, %i4, %i0
> -ENDPROC(NG_ret_i2_plus_i4_minus_8)
> +ENDPROC(NG_ret_i2_plus_i4_plus_8)
>  ENTRY(NG_ret_i2_plus_8)
>  	ba,pt	%xcc, __restore_asi
>  	 add	%i2, 8, %i0
> @@ -160,6 +161,12 @@ ENTRY(NG_ret_i2_and_7_plus_i4)
>  	ba,pt	%xcc, __restore_asi
>  	 add	%i2, %i4, %i0
>  ENDPROC(NG_ret_i2_and_7_plus_i4)
> +ENTRY(NG_ret_i2_and_7_plus_i4_plus_8)
> +	and	%i2, 7, %i2
> +	add	%i4, 8, %i4
> +	ba,pt	%xcc, __restore_asi
> +	 add	%i2, %i4, %i0
> +ENDPROC(NG_ret_i2_and_7_plus_i4)
>  #endif
>  
>  	.align		64
> @@ -405,13 +412,13 @@ FUNC_NAME:	/* %i0=dst, %i1=src, %i2=len */
>  	andn		%i2, 0xf, %i4
>  	and		%i2, 0xf, %i2
>  1:	subcc		%i4, 0x10, %i4
> -	EX_LD(LOAD(ldx, %i1, %o4), NG_ret_i2_plus_i4)
> +	EX_LD(LOAD(ldx, %i1, %o4), NG_ret_i2_plus_i4_plus_16)
>  	add		%i1, 0x08, %i1
> -	EX_LD(LOAD(ldx, %i1, %g1), NG_ret_i2_plus_i4)
> +	EX_LD(LOAD(ldx, %i1, %g1), NG_ret_i2_plus_i4_plus_16)
>  	sub		%i1, 0x08, %i1
> -	EX_ST(STORE(stx, %o4, %i1 + %i3), NG_ret_i2_plus_i4)
> +	EX_ST(STORE(stx, %o4, %i1 + %i3), NG_ret_i2_plus_i4_plus_16)
>  	add		%i1, 0x8, %i1
> -	EX_ST(STORE(stx, %g1, %i1 + %i3), NG_ret_i2_plus_i4_minus_8)
> +	EX_ST(STORE(stx, %g1, %i1 + %i3), NG_ret_i2_plus_i4_plus_8)
>  	bgu,pt		%XCC, 1b
>  	 add		%i1, 0x8, %i1
>  73:	andcc		%i2, 0x8, %g0
> @@ -468,7 +475,7 @@ FUNC_NAME:	/* %i0=dst, %i1=src, %i2=len */
>  	subcc		%i4, 0x8, %i4
>  	srlx		%g3, %i3, %i5
>  	or		%i5, %g2, %i5
> -	EX_ST(STORE(stx, %i5, %o0), NG_ret_i2_and_7_plus_i4)
> +	EX_ST(STORE(stx, %i5, %o0), NG_ret_i2_and_7_plus_i4_plus_8)
>  	add		%o0, 0x8, %o0
>  	bgu,pt		%icc, 1b
>  	 sllx		%g3, %g1, %g2
> -- 
> 2.50.1
> 
> 

-- 
  René Rebe, ExactCODE GmbH, Berlin, Germany
  https://exactcode.com | https://t2linux.com | https://rene.rebe.de

Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara

[John Paul Adrian Glaubitz]

Hi Rene,

On Tue, 2025-09-02 at 18:40 +0200, Rene Rebe wrote:
> Hi,
> 
> From: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> 
> > Fixes: 7ae3aaf53f16 ("sparc64: Convert NGcopy_{from,to}_user to accurate exception reporting.")
> > Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> 
> Tested-by: René Rebe <rene@exactcode.com> # UltraSparc T4 SPARC T4-1 Server

Thanks for the testing! However, this actually needs to be tested on a SPARC T1
as both T2 and T4 have their own implementation that is being used. Testing on a
T4 will therefore not invoke this particular code unless you modify the kernel in
head_64.S to employ the Niagara 1 code on Niagara 4.

Do you happen to have a SPARC T1?

Adrian

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

Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara

[Rene Rebe]

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

> Hi Rene,
> 
> On Tue, 2025-09-02 at 18:40 +0200, Rene Rebe wrote:
> > Hi,
> > 
> > From: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> > 
> > > Fixes: 7ae3aaf53f16 ("sparc64: Convert NGcopy_{from,to}_user to accurate exception reporting.")
> > > Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> > 
> > Tested-by: René Rebe <rene@exactcode.com> # UltraSparc T4 SPARC T4-1 Server
> 
> Thanks for the testing! However, this actually needs to be tested on a SPARC T1
> as both T2 and T4 have their own implementation that is being used. Testing on a
> T4 will therefore not invoke this particular code unless you modify the kernel in
> head_64.S to employ the Niagara 1 code on Niagara 4.

Ah right, sorry, IIRC you wrote that :-/

> Do you happen to have a SPARC T1?

Unfortuantely not. A T2 user might have one, but I could also modify
the kernel and use the less optimized T1 code if that helps, ...

    René

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

-- 
  René Rebe, ExactCODE GmbH, Berlin, Germany
  https://exactcode.com | https://t2linux.com | https://rene.rebe.de

Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara

[John Paul Adrian Glaubitz]

On Tue, 2025-09-02 at 18:51 +0200, Rene Rebe wrote:
> From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> 
> > Hi Rene,
> > 
> > On Tue, 2025-09-02 at 18:40 +0200, Rene Rebe wrote:
> > > Hi,
> > > 
> > > From: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> > > 
> > > > Fixes: 7ae3aaf53f16 ("sparc64: Convert NGcopy_{from,to}_user to accurate exception reporting.")
> > > > Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> > > 
> > > Tested-by: René Rebe <rene@exactcode.com> # UltraSparc T4 SPARC T4-1 Server
> > 
> > Thanks for the testing! However, this actually needs to be tested on a SPARC T1
> > as both T2 and T4 have their own implementation that is being used. Testing on a
> > T4 will therefore not invoke this particular code unless you modify the kernel in
> > head_64.S to employ the Niagara 1 code on Niagara 4.
> 
> Ah right, sorry, IIRC you wrote that :-/
> 
> > Do you happen to have a SPARC T1?
> 
> Unfortuantely not. A T2 user might have one, but I could also modify
> the kernel and use the less optimized T1 code if that helps, ...

I have done that already to test the Niagara 1 code on Niagara 4.

However, it would be nice to test on a real T1. Unfortunately, I haven't found
anyone yet who got one. If you could ask your users, that would be great.

Otherwise, we will have to go with the current level of testing.

Adrian

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

Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara

[Rene Rebe]

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

> On Tue, 2025-09-02 at 18:51 +0200, Rene Rebe wrote:
> > From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> > 
> > > Hi Rene,
> > > 
> > > On Tue, 2025-09-02 at 18:40 +0200, Rene Rebe wrote:
> > > > Hi,
> > > > 
> > > > From: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> > > > 
> > > > > Fixes: 7ae3aaf53f16 ("sparc64: Convert NGcopy_{from,to}_user to accurate exception reporting.")
> > > > > Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> > > > 
> > > > Tested-by: René Rebe <rene@exactcode.com> # UltraSparc T4 SPARC T4-1 Server
> > > 
> > > Thanks for the testing! However, this actually needs to be tested on a SPARC T1
> > > as both T2 and T4 have their own implementation that is being used. Testing on a
> > > T4 will therefore not invoke this particular code unless you modify the kernel in
> > > head_64.S to employ the Niagara 1 code on Niagara 4.
> > 
> > Ah right, sorry, IIRC you wrote that :-/
> > 
> > > Do you happen to have a SPARC T1?
> > 
> > Unfortuantely not. A T2 user might have one, but I could also modify
> > the kernel and use the less optimized T1 code if that helps, ...
> 
> I have done that already to test the Niagara 1 code on Niagara 4.
> 
> However, it would be nice to test on a real T1. Unfortunately, I haven't found
> anyone yet who got one. If you could ask your users, that would be great.

someone in our Discord probably has one in the basement or attic, but
the chances of them turning just that system on the next days or weeks
is probably rather slim.

I guess testing all the "popular" systems: vintage collected
workstations and affortable more modern higher performance T4 servers
is all we got for the near future for this patches.

       René

> Otherwise, we will have to go with the current level of testing.
> 
> Adrian
> 
> -- 
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer
> `. `'   Physicist
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

-- 
  René Rebe, ExactCODE GmbH, Berlin, Germany
  https://exactcode.com | https://t2linux.com | https://rene.rebe.de

Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara

[John Paul Adrian Glaubitz]

On Tue, 2025-09-02 at 19:04 +0200, Rene Rebe wrote:
> someone in our Discord probably has one in the basement or attic, but
> the chances of them turning just that system on the next days or weeks
> is probably rather slim.
> 
> I guess testing all the "popular" systems: vintage collected
> workstations and affortable more modern higher performance T4 servers
> is all we got for the near future for this patches.

I just realized that QEMU can emulate a Niagara CPU, so we can test there:

https://www.qemu.org/docs/master/system/target-sparc64.html

Maybe you can test independently on QEMU as well using your kernel, then
your Tested-by will become valid.

Adrian

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

Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara

[René Rebe]

Hi,

> On 2. Sep 2025, at 18:53, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> 
> On Tue, 2025-09-02 at 18:51 +0200, Rene Rebe wrote:
>> From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
>> 
>>> Hi Rene,
>>> 
>>> On Tue, 2025-09-02 at 18:40 +0200, Rene Rebe wrote:
>>>> Hi,
>>>> 
>>>> From: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
>>>> 
>>>>> Fixes: 7ae3aaf53f16 ("sparc64: Convert NGcopy_{from,to}_user to accurate exception reporting.")
>>>>> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
>>>> 
>>>> Tested-by: René Rebe <rene@exactcode.com> # UltraSparc T4 SPARC T4-1 Server
>>> 
>>> Thanks for the testing! However, this actually needs to be tested on a SPARC T1
>>> as both T2 and T4 have their own implementation that is being used. Testing on a
>>> T4 will therefore not invoke this particular code unless you modify the kernel in
>>> head_64.S to employ the Niagara 1 code on Niagara 4.
>> 
>> Ah right, sorry, IIRC you wrote that :-/
>> 
>>> Do you happen to have a SPARC T1?
>> 
>> Unfortuantely not. A T2 user might have one, but I could also modify
>> the kernel and use the less optimized T1 code if that helps, ...
> 
> I have done that already to test the Niagara 1 code on Niagara 4.
> 
> However, it would be nice to test on a real T1. Unfortunately, I haven't found
> anyone yet who got one. If you could ask your users, that would be great.
> 
> Otherwise, we will have to go with the current level of testing.

In case someone has a T1 or M8 in their basement -or otherwise likes to test new things-
here is the current WIP pre-release build with basically everything as up-to-date as possible 
and the patches included:

	https://dl.t2sde.org/binary/2025/incoming/t2-25.9-sparc64-base-wayland-glibc-gcc-ultrasparc3.iso

the .d directory has the content for cherry picking. Even latest Firefox 142 works (at least it did last
week when I patched and tested it ;-)

	René

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

-- 
https://exactco.de - https://t2linux.com - https://rene.rebe.de

[PATCH 4/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara 4

[Michael Karcher]

Fixes: 957077048009 ("sparc64: Convert NG4copy_{from,to}_user to accurate exception reporting.")
Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
---
 arch/sparc/lib/NG4memcpy.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sparc/lib/NG4memcpy.S b/arch/sparc/lib/NG4memcpy.S
index 7ad58ebe0d00..df0ec1bd1948 100644
--- a/arch/sparc/lib/NG4memcpy.S
+++ b/arch/sparc/lib/NG4memcpy.S
@@ -281,7 +281,7 @@ FUNC_NAME:	/* %o0=dst, %o1=src, %o2=len */
 	subcc		%o5, 0x20, %o5
 	EX_ST(STORE(stx, %g1, %o0 + 0x00), memcpy_retl_o2_plus_o5_plus_32)
 	EX_ST(STORE(stx, %g2, %o0 + 0x08), memcpy_retl_o2_plus_o5_plus_24)
-	EX_ST(STORE(stx, GLOBAL_SPARE, %o0 + 0x10), memcpy_retl_o2_plus_o5_plus_24)
+	EX_ST(STORE(stx, GLOBAL_SPARE, %o0 + 0x10), memcpy_retl_o2_plus_o5_plus_16)
 	EX_ST(STORE(stx, %o4, %o0 + 0x18), memcpy_retl_o2_plus_o5_plus_8)
 	bne,pt		%icc, 1b
 	 add		%o0, 0x20, %o0
-- 
2.50.1

Re: [PATCH 4/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara 4

[John Paul Adrian Glaubitz]

Hello Michael,

On Tue, 2025-08-26 at 18:03 +0200, Michael Karcher wrote:
> Fixes: 957077048009 ("sparc64: Convert NG4copy_{from,to}_user to accurate exception reporting.")
> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> ---
>  arch/sparc/lib/NG4memcpy.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/sparc/lib/NG4memcpy.S b/arch/sparc/lib/NG4memcpy.S
> index 7ad58ebe0d00..df0ec1bd1948 100644
> --- a/arch/sparc/lib/NG4memcpy.S
> +++ b/arch/sparc/lib/NG4memcpy.S
> @@ -281,7 +281,7 @@ FUNC_NAME:	/* %o0=dst, %o1=src, %o2=len */
>  	subcc		%o5, 0x20, %o5
>  	EX_ST(STORE(stx, %g1, %o0 + 0x00), memcpy_retl_o2_plus_o5_plus_32)
>  	EX_ST(STORE(stx, %g2, %o0 + 0x08), memcpy_retl_o2_plus_o5_plus_24)
> -	EX_ST(STORE(stx, GLOBAL_SPARE, %o0 + 0x10), memcpy_retl_o2_plus_o5_plus_24)
> +	EX_ST(STORE(stx, GLOBAL_SPARE, %o0 + 0x10), memcpy_retl_o2_plus_o5_plus_16)
>  	EX_ST(STORE(stx, %o4, %o0 + 0x18), memcpy_retl_o2_plus_o5_plus_8)
>  	bne,pt		%icc, 1b
>  	 add		%o0, 0x20, %o0

Applied this patch to Debian's kernel from unstable, got the following backtrace during boot:

[   11.109771] Unable to handle kernel paging request at virtual address fff80000c0000000
[   11.109824] tsk->{mm,active_mm}->context = 0000000000000139
[   11.109842] tsk->{mm,active_mm}->pgd = fff800001bb6c000
[   11.109859]               \|/ ____ \|/
[   11.109859]               "@'/ .. \`@"
[   11.109859]               /_| \__/ |_\
[   11.109859]                  \__U_/
[   11.109885] cryptomgr_test(411): Oops [#1]
[   11.109908] CPU: 0 UID: 0 PID: 411 Comm: cryptomgr_test Not tainted 6.16.3+1-sparc64-smp #1 NONE  Debian 6.16.3-1+sparc64 
[   11.109939] TSTATE: 0000008811001601 TPC: 000000001026a048 TNPC: 000000001026a04c Y: 00001000    Not tainted
[   11.109963] TPC: <sha512_sparc64_transform+0x48/0x160 [sha512_sparc64]>
[   11.109990] g0: 0000000000000000 g1: 0000000000000000 g2: 0000000000000000 g3: 0000000000000000
[   11.110010] g4: fff800001bcd7080 g5: fff800059cef6000 g6: fff8000018e68000 g7: 000000001026a000
[   11.110031] o0: fff8000018ada7e8 o1: fff80000c0000000 o2: fffffffffeb1cc80 o3: 00000000f70e5800
[   11.110052] o4: 0000000068581400 o5: 0000000000000000 sp: fff8000018e6af41 ret_pc: 000000001026a5c8
[   11.110072] RPC: <sha512_sparc64_update+0x48/0x60 [sha512_sparc64]>
[   11.110093] l0: 000000000000000a l1: 0000000000000000 l2: 0000000000000000 l3: 0000000000000000
[   11.110113] l4: 0000000000000000 l5: ffffffffffffffff l6: 0000000000000000 l7: fff8000014263c00
[   11.110133] i0: 0000000000000000 i1: fff8000018e64000 i2: 0000000000000000 i3: 00000000ffc00b31
[   11.110152] i4: 0000000068581511 i5: 0000000064f98fa7 i6: fff8000018e6aff1 i7: 0000000000980a1c
[   11.110173] I7: <crypto_shash_finup+0x17c/0x220>
[   11.110205] Call Trace:
[   11.110218] [<0000000000980a1c>] crypto_shash_finup+0x17c/0x220
[   11.110240] [<0000000000989104>] test_shash_vec_cfg+0x2a4/0x580
[   11.110270] [<000000000098d688>] __alg_test_hash.isra.0+0x1a8/0x360
[   11.110291] [<000000000098d920>] alg_test_hash+0xe0/0x140
[   11.110312] [<000000000098bf9c>] alg_test+0x17c/0x7a0
[   11.110332] [<0000000000987b98>] cryptomgr_test+0x18/0x60
[   11.110352] [<00000000004ac704>] kthread+0x104/0x280
[   11.110382] [<00000000004060c8>] ret_from_fork+0x1c/0x2c
[   11.110410] [<0000000000000000>] 0x0
[   11.110427] Disabling lock debugging due to kernel taint
[   11.110442] Caller[0000000000980a1c]: crypto_shash_finup+0x17c/0x220
[   11.110464] Caller[0000000000989104]: test_shash_vec_cfg+0x2a4/0x580
[   11.110485] Caller[000000000098d688]: __alg_test_hash.isra.0+0x1a8/0x360
[   11.110506] Caller[000000000098d920]: alg_test_hash+0xe0/0x140
[   11.110526] Caller[000000000098bf9c]: alg_test+0x17c/0x7a0
[   11.110545] Caller[0000000000987b98]: cryptomgr_test+0x18/0x60
[   11.110565] Caller[00000000004ac704]: kthread+0x104/0x280
[   11.110585] Caller[00000000004060c8]: ret_from_fork+0x1c/0x2c
[   11.110606] Caller[0000000000000000]: 0x0
[   11.110622] Instruction DUMP:
[   11.110626]  d91a2030 
[   11.110640]  12600020 
[   11.110653]  dd1a2038 
[   11.110666] <e11a6000>
[   11.110678]  e51a6008 
[   11.110691]  e91a6010 
[   11.110704]  ed1a6018 
[   11.110716]  f11a6020 
[   11.110728]  f51a6028 
[   11.110741] 
[   11.144051] Unable to handle kernel paging request at virtual address fff80000c0000000
[   11.144098] tsk->{mm,active_mm}->context = 0000000000000144
[   11.144113] tsk->{mm,active_mm}->pgd = fff800001c2d0000
[   11.144127]               \|/ ____ \|/
[   11.144127]               "@'/ .. \`@"
[   11.144127]               /_| \__/ |_\
[   11.144127]                  \__U_/
[   11.144150] cryptomgr_test(412): Oops [#2]
[   11.144171] CPU: 1 UID: 0 PID: 412 Comm: cryptomgr_test Tainted: G      D             6.16.3+1-sparc64-smp #1 NONE  Debian 6.16.3-1+sparc64 
[   11.144202] Tainted: [D]=DIE
[   11.144215] TSTATE: 0000008811001601 TPC: 000000001026a048 TNPC: 000000001026a04c Y: 00001000    Tainted: G      D            
[   11.144237] TPC: <sha512_sparc64_transform+0x48/0x160 [sha512_sparc64]>
[   11.144260] g0: 0000000000000000 g1: 0000000000000000 g2: 0000000000000000 g3: 0000000000000000
[   11.144278] g4: fff800001494ec40 g5: fff800059cf16000 g6: fff800001bcb4000 g7: 000000001026a000
[   11.144296] o0: fff8000018fbd328 o1: fff80000c0000000 o2: fffffffffeac0280 o3: 000000005f1d3400
[   11.144314] o4: 000000002b3e6c00 o5: 0000000000000000 sp: fff800001bcb6f41 ret_pc: 000000001026a5c8
[   11.144333] RPC: <sha512_sparc64_update+0x48/0x60 [sha512_sparc64]>
[   11.144352] l0: 000000000000000a l1: 0000000000000000 l2: 0000000000000000 l3: 0000000000000000
[   11.144370] l4: 0000000000000000 l5: ffffffffffffffff l6: 0000000000000000 l7: 00000000007c4ee0
[   11.144388] i0: 0000000000000000 i1: fff8000016014000 i2: 0000000000000000 i3: 00000000ade682d1
[   11.144406] i4: 000000002b3e6c1f i5: 00000000fb41bd6b i6: fff800001bcb6ff1 i7: 0000000000980a1c
[   11.144424] I7: <crypto_shash_finup+0x17c/0x220>
[   11.144448] Call Trace:
[   11.144460] [<0000000000980a1c>] crypto_shash_finup+0x17c/0x220
[   11.144480] [<0000000000989104>] test_shash_vec_cfg+0x2a4/0x580
[   11.144504] [<000000000098d688>] __alg_test_hash.isra.0+0x1a8/0x360
[   11.144523] [<000000000098d920>] alg_test_hash+0xe0/0x140
[   11.144542] [<000000000098bf9c>] alg_test+0x17c/0x7a0
[   11.144560] [<0000000000987b98>] cryptomgr_test+0x18/0x60
[   11.144579] [<00000000004ac704>] kthread+0x104/0x280
[   11.144601] [<00000000004060c8>] ret_from_fork+0x1c/0x2c
[   11.144624] [<0000000000000000>] 0x0
[   11.144640] Caller[0000000000980a1c]: crypto_shash_finup+0x17c/0x220
[   11.144658] Caller[0000000000989104]: test_shash_vec_cfg+0x2a4/0x580
[   11.144677] Caller[000000000098d688]: __alg_test_hash.isra.0+0x1a8/0x360
[   11.144695] Caller[000000000098d920]: alg_test_hash+0xe0/0x140
[   11.144714] Caller[000000000098bf9c]: alg_test+0x17c/0x7a0
[   11.144731] Caller[0000000000987b98]: cryptomgr_test+0x18/0x60
[   11.144749] Caller[00000000004ac704]: kthread+0x104/0x280
[   11.144767] Caller[00000000004060c8]: ret_from_fork+0x1c/0x2c
[   11.144785] Caller[0000000000000000]: 0x0
[   11.144800] Instruction DUMP:
[   11.144804]  d91a2030 
[   11.144816]  12600020 
[   11.144828]  dd1a2038 
[   11.144839] <e11a6000>
[   11.144851]  e51a6008 
[   11.144862]  e91a6010 
[   11.144874]  ed1a6018 
[   11.144885]  f11a6020 
[   11.144896]  f51a6028 
[   11.144908]

However, I made the observation that the Debian kernel started to cause backtraces
even without the patch with newer kernels:

[    1.764073] ------------[ cut here ]------------
[    1.764113] WARNING: CPU: 23 PID: 194 at lib/kobject.c:734 kobject_put+0x64/0x240
[    1.764150] kobject: '(null)' ((____ptrval____)): is not initialized, yet kobject_put() is being called.
[    1.764169] Modules linked in:
[    1.764190] CPU: 23 UID: 0 PID: 194 Comm: kworker/u256:16 Not tainted 6.12.38+deb13-sparc64-smp #1  Debian 6.12.38-1
[    1.764203] Workqueue: async async_run_entry_fn
[    1.764218] Call Trace:
[    1.764221] [<0000000000f11864>] dump_stack+0x8/0x18
[    1.764234] [<000000000046e15c>] __warn+0xdc/0x140
[    1.764244] [<000000000046e2d8>] warn_slowpath_fmt+0x118/0x140
[    1.764251] [<0000000000ec8024>] kobject_put+0x64/0x240
[    1.764260] [<000000000072d98c>] sysfs_slab_release+0xc/0x20
[    1.764273] [<00000000006dc91c>] kmem_cache_destroy+0xdc/0x1a0
[    1.764286] [<00000000009593c4>] bioset_exit+0x144/0x1e0
[    1.764299] [<000000000097a8d4>] disk_release+0x54/0x120
[    1.764311] [<0000000000b94a0c>] device_release+0x2c/0xa0
[    1.764322] [<0000000000ec8088>] kobject_put+0xc8/0x240
[    1.764330] [<0000000000b94c74>] put_device+0x14/0x40
[    1.764337] [<000000000097ac58>] put_disk+0x18/0x40
[    1.764346] [<000000000140c2c8>] floppy_async_init+0xbec/0xd10
[    1.764357] [<00000000004a0cc8>] async_run_entry_fn+0x28/0x160
[    1.764364] [<000000000049091c>] process_one_work+0x15c/0x3c0
[    1.764375] [<0000000000490f24>] worker_thread+0x164/0x3e0
[    1.764384] ---[ end trace 0000000000000000 ]---
[    1.764546] ------------[ cut here ]------------
[    1.764557] WARNING: CPU: 23 PID: 194 at lib/refcount.c:28 refcount_warn_saturate+0x18c/0x1a0
[    1.764581] refcount_t: underflow; use-after-free.
[    1.764592] Modules linked in:
[    1.764608] CPU: 23 UID: 0 PID: 194 Comm: kworker/u256:16 Tainted: G        W          6.12.38+deb13-sparc64-smp #1  Debian 6.12.38-1
[    1.764618] Tainted: [W]=WARN
[    1.764621] Workqueue: async async_run_entry_fn
[    1.764629] Call Trace:
[    1.764631] [<0000000000f11864>] dump_stack+0x8/0x18
[    1.764639] [<000000000046e15c>] __warn+0xdc/0x140
[    1.764646] [<000000000046e2d8>] warn_slowpath_fmt+0x118/0x140
[    1.764652] [<00000000009d4d2c>] refcount_warn_saturate+0x18c/0x1a0
[    1.764659] [<0000000000ec8134>] kobject_put+0x174/0x240
[    1.764667] [<000000000072d98c>] sysfs_slab_release+0xc/0x20
[    1.764676] [<00000000006dc91c>] kmem_cache_destroy+0xdc/0x1a0
[    1.764684] [<00000000009593c4>] bioset_exit+0x144/0x1e0
[    1.764691] [<000000000097a8d4>] disk_release+0x54/0x120
[    1.764699] [<0000000000b94a0c>] device_release+0x2c/0xa0
[    1.764707] [<0000000000ec8088>] kobject_put+0xc8/0x240
[    1.764714] [<0000000000b94c74>] put_device+0x14/0x40
[    1.764721] [<000000000097ac58>] put_disk+0x18/0x40
[    1.764729] [<000000000140c2c8>] floppy_async_init+0xbec/0xd10
[    1.764737] [<00000000004a0cc8>] async_run_entry_fn+0x28/0x160
[    1.764744] [<000000000049091c>] process_one_work+0x15c/0x3c0
[    1.764752] ---[ end trace 0000000000000000 ]---

Upstream kernels don't show this problem. This is either related to the compiler version
being used or some Debian-specific patches or configuration options.

Adrian

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

Re: [PATCH 4/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara 4

[John Paul Adrian Glaubitz]

Hello,

On Tue, 2025-08-26 at 18:03 +0200, Michael Karcher wrote:
> Fixes: 957077048009 ("sparc64: Convert NG4copy_{from,to}_user to accurate exception reporting.")
> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> ---
>  arch/sparc/lib/NG4memcpy.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/sparc/lib/NG4memcpy.S b/arch/sparc/lib/NG4memcpy.S
> index 7ad58ebe0d00..df0ec1bd1948 100644
> --- a/arch/sparc/lib/NG4memcpy.S
> +++ b/arch/sparc/lib/NG4memcpy.S
> @@ -281,7 +281,7 @@ FUNC_NAME:	/* %o0=dst, %o1=src, %o2=len */
>  	subcc		%o5, 0x20, %o5
>  	EX_ST(STORE(stx, %g1, %o0 + 0x00), memcpy_retl_o2_plus_o5_plus_32)
>  	EX_ST(STORE(stx, %g2, %o0 + 0x08), memcpy_retl_o2_plus_o5_plus_24)
> -	EX_ST(STORE(stx, GLOBAL_SPARE, %o0 + 0x10), memcpy_retl_o2_plus_o5_plus_24)
> +	EX_ST(STORE(stx, GLOBAL_SPARE, %o0 + 0x10), memcpy_retl_o2_plus_o5_plus_16)
>  	EX_ST(STORE(stx, %o4, %o0 + 0x18), memcpy_retl_o2_plus_o5_plus_8)
>  	bne,pt		%icc, 1b
>  	 add		%o0, 0x20, %o0

Verified to not cause any regressions on SPARC T4. Whether it improved anything is
hard to say. It might be that previously observed crashes after long uptimes are
gone now.

Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Adrian

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

Re: [PATCH 4/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara 4

[Michael Karcher]

Am 28.08.2025 um 22:21 schrieb John Paul Adrian Glaubitz:
> On Tue, 2025-08-26 at 18:03 +0200, Michael Karcher wrote:
>>   	EX_ST(STORE(stx, %g1, %o0 + 0x00), memcpy_retl_o2_plus_o5_plus_32)
>>   	EX_ST(STORE(stx, %g2, %o0 + 0x08), memcpy_retl_o2_plus_o5_plus_24)
>> -	EX_ST(STORE(stx, GLOBAL_SPARE, %o0 + 0x10), memcpy_retl_o2_plus_o5_plus_24)
>> +	EX_ST(STORE(stx, GLOBAL_SPARE, %o0 + 0x10), memcpy_retl_o2_plus_o5_plus_16)
>>   	EX_ST(STORE(stx, %o4, %o0 + 0x18), memcpy_retl_o2_plus_o5_plus_8)
> Verified to not cause any regressions on SPARC T4. Whether it improved anything is
> hard to say. It might be that previously observed crashes after long uptimes are
> gone now.

I don't see how my patch will generate observable improvements. The patch is
"obviously correct", as it fixes the arithmetic progression 32/24/16/8, which
was originally interrupted, and also my test program agrees that the return
value is what it is "supposed to be" after applying the patch.

The old (likely unintended) code returns 8 more bytes left to copy than there
actually are left. This means that all bytes that are not indicated as "left
to copy" have actually been successfully copied, as well as 8 "hidden" bytes.
So the return value is kind-of valid.

Thus I think verifying that there are no regressions and reviewing the code
are the only quality assurance measures we can apply to this patch. I'm afraid
that this patch most likely will not fix the previously observed crashes, as
in this case, the return value was never too low (which could cause the kernel
to trust ouput bytes that have not been copied), and always less than the
amount requested to copy. Returning more bytes left than actually requested
can cause any kind of strange behaviour, as this is not expected by the callers
of this function, and can generate invalid states (like we observed with
negative file offsets in folio-enabled ext4 code with transparent huge pages
enabled on UltraSparc III).

Thanks for testing that there are indeed no regressions!

Kind regards,
   Michael Karcher