* Fix accurate exception reporting in SPARC assembly
@ 2025-08-26 16:03 Michael Karcher
2025-08-26 16:03 ` [PATCH 1/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC Michael Karcher
` (3 more replies)
0 siblings, 4 replies; 23+ messages in thread
From: Michael Karcher @ 2025-08-26 16:03 UTC (permalink / raw)
To: linux-kernel
Cc: sparclinux, Michael Karcher, Andreas Larsson,
John Paul Adrian Glaubitz, Anthony Yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 1/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC
2025-08-26 16:03 Fix accurate exception reporting in SPARC assembly Michael Karcher
@ 2025-08-26 16:03 ` Michael Karcher
2025-08-29 10:53 ` John Paul Adrian Glaubitz
2025-09-02 16:33 ` Rene Rebe
2025-08-26 16:03 ` [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III Michael Karcher
` (2 subsequent siblings)
3 siblings, 2 replies; 23+ messages in thread
From: Michael Karcher @ 2025-08-26 16:03 UTC (permalink / raw)
To: linux-kernel
Cc: sparclinux, Michael Karcher, Andreas Larsson,
John Paul Adrian Glaubitz, Anthony Yznaga
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
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III
2025-08-26 16:03 Fix accurate exception reporting in SPARC assembly Michael Karcher
2025-08-26 16:03 ` [PATCH 1/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC Michael Karcher
@ 2025-08-26 16:03 ` Michael Karcher
2025-08-27 6:34 ` John Paul Adrian Glaubitz
` (3 more replies)
2025-08-26 16:03 ` [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara Michael Karcher
2025-08-26 16:03 ` [PATCH 4/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara 4 Michael Karcher
3 siblings, 4 replies; 23+ messages in thread
From: Michael Karcher @ 2025-08-26 16:03 UTC (permalink / raw)
To: linux-kernel
Cc: sparclinux, Michael Karcher, Andreas Larsson,
John Paul Adrian Glaubitz, Anthony Yznaga
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
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara
2025-08-26 16:03 Fix accurate exception reporting in SPARC assembly Michael Karcher
2025-08-26 16:03 ` [PATCH 1/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC Michael Karcher
2025-08-26 16:03 ` [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III Michael Karcher
@ 2025-08-26 16:03 ` Michael Karcher
2025-08-29 21:44 ` John Paul Adrian Glaubitz
2025-09-02 16:40 ` Rene Rebe
2025-08-26 16:03 ` [PATCH 4/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara 4 Michael Karcher
3 siblings, 2 replies; 23+ messages in thread
From: Michael Karcher @ 2025-08-26 16:03 UTC (permalink / raw)
To: linux-kernel
Cc: sparclinux, Michael Karcher, Andreas Larsson,
John Paul Adrian Glaubitz, Anthony Yznaga
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
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH 4/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara 4
2025-08-26 16:03 Fix accurate exception reporting in SPARC assembly Michael Karcher
` (2 preceding siblings ...)
2025-08-26 16:03 ` [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara Michael Karcher
@ 2025-08-26 16:03 ` Michael Karcher
2025-08-27 6:37 ` John Paul Adrian Glaubitz
2025-08-28 20:21 ` John Paul Adrian Glaubitz
3 siblings, 2 replies; 23+ messages in thread
From: Michael Karcher @ 2025-08-26 16:03 UTC (permalink / raw)
To: linux-kernel
Cc: sparclinux, Michael Karcher, Andreas Larsson,
John Paul Adrian Glaubitz, Anthony Yznaga
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
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III
2025-08-26 16:03 ` [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III Michael Karcher
@ 2025-08-27 6:34 ` John Paul Adrian Glaubitz
2025-08-28 15:53 ` John Paul Adrian Glaubitz
` (2 subsequent siblings)
3 siblings, 0 replies; 23+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-27 6:34 UTC (permalink / raw)
To: Michael Karcher, linux-kernel; +Cc: sparclinux, Andreas Larsson, Anthony Yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 4/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara 4
2025-08-26 16:03 ` [PATCH 4/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara 4 Michael Karcher
@ 2025-08-27 6:37 ` John Paul Adrian Glaubitz
2025-08-28 20:21 ` John Paul Adrian Glaubitz
1 sibling, 0 replies; 23+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-27 6:37 UTC (permalink / raw)
To: Michael Karcher, linux-kernel; +Cc: sparclinux, Andreas Larsson, Anthony Yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III
2025-08-26 16:03 ` [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III Michael Karcher
2025-08-27 6:34 ` John Paul Adrian Glaubitz
@ 2025-08-28 15:53 ` John Paul Adrian Glaubitz
2025-08-30 1:57 ` Anthony Yznaga
2025-09-02 16:38 ` Rene Rebe
3 siblings, 0 replies; 23+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-28 15:53 UTC (permalink / raw)
To: Michael Karcher, linux-kernel; +Cc: sparclinux, Andreas Larsson, Anthony Yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 4/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara 4
2025-08-26 16:03 ` [PATCH 4/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara 4 Michael Karcher
2025-08-27 6:37 ` John Paul Adrian Glaubitz
@ 2025-08-28 20:21 ` John Paul Adrian Glaubitz
2025-08-29 13:24 ` Michael Karcher
1 sibling, 1 reply; 23+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-28 20:21 UTC (permalink / raw)
To: Michael Karcher, linux-kernel; +Cc: sparclinux, Andreas Larsson, Anthony Yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 1/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC
2025-08-26 16:03 ` [PATCH 1/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC Michael Karcher
@ 2025-08-29 10:53 ` John Paul Adrian Glaubitz
2025-09-02 16:33 ` Rene Rebe
1 sibling, 0 replies; 23+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-29 10:53 UTC (permalink / raw)
To: Michael Karcher, linux-kernel; +Cc: sparclinux, Andreas Larsson, Anthony Yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 4/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara 4
2025-08-28 20:21 ` John Paul Adrian Glaubitz
@ 2025-08-29 13:24 ` Michael Karcher
0 siblings, 0 replies; 23+ messages in thread
From: Michael Karcher @ 2025-08-29 13:24 UTC (permalink / raw)
To: John Paul Adrian Glaubitz, linux-kernel
Cc: sparclinux, Andreas Larsson, Anthony Yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara
2025-08-26 16:03 ` [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara Michael Karcher
@ 2025-08-29 21:44 ` John Paul Adrian Glaubitz
2025-09-02 16:40 ` Rene Rebe
1 sibling, 0 replies; 23+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-29 21:44 UTC (permalink / raw)
To: Michael Karcher, linux-kernel; +Cc: sparclinux, Andreas Larsson, Anthony Yznaga
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
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III
2025-08-26 16:03 ` [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III Michael Karcher
2025-08-27 6:34 ` John Paul Adrian Glaubitz
2025-08-28 15:53 ` John Paul Adrian Glaubitz
@ 2025-08-30 1:57 ` Anthony Yznaga
2025-08-30 8:35 ` Michael Karcher
2025-09-02 16:38 ` Rene Rebe
3 siblings, 1 reply; 23+ messages in thread
From: Anthony Yznaga @ 2025-08-30 1:57 UTC (permalink / raw)
To: Michael Karcher, linux-kernel
Cc: sparclinux, Andreas Larsson, John Paul Adrian Glaubitz
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III
2025-08-30 1:57 ` Anthony Yznaga
@ 2025-08-30 8:35 ` Michael Karcher
0 siblings, 0 replies; 23+ messages in thread
From: Michael Karcher @ 2025-08-30 8:35 UTC (permalink / raw)
To: Anthony Yznaga, linux-kernel
Cc: sparclinux, Andreas Larsson, John Paul Adrian Glaubitz
>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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 1/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC
2025-08-26 16:03 ` [PATCH 1/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC Michael Karcher
2025-08-29 10:53 ` John Paul Adrian Glaubitz
@ 2025-09-02 16:33 ` Rene Rebe
1 sibling, 0 replies; 23+ messages in thread
From: Rene Rebe @ 2025-09-02 16:33 UTC (permalink / raw)
To: kernel; +Cc: linux-kernel, sparclinux, andreas, glaubitz, anthony.yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III
2025-08-26 16:03 ` [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III Michael Karcher
` (2 preceding siblings ...)
2025-08-30 1:57 ` Anthony Yznaga
@ 2025-09-02 16:38 ` Rene Rebe
3 siblings, 0 replies; 23+ messages in thread
From: Rene Rebe @ 2025-09-02 16:38 UTC (permalink / raw)
To: kernel; +Cc: linux-kernel, sparclinux, andreas, glaubitz, anthony.yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara
2025-08-26 16:03 ` [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara Michael Karcher
2025-08-29 21:44 ` John Paul Adrian Glaubitz
@ 2025-09-02 16:40 ` Rene Rebe
2025-09-02 16:47 ` John Paul Adrian Glaubitz
1 sibling, 1 reply; 23+ messages in thread
From: Rene Rebe @ 2025-09-02 16:40 UTC (permalink / raw)
To: kernel; +Cc: linux-kernel, sparclinux, andreas, glaubitz, anthony.yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara
2025-09-02 16:40 ` Rene Rebe
@ 2025-09-02 16:47 ` John Paul Adrian Glaubitz
2025-09-02 16:51 ` Rene Rebe
0 siblings, 1 reply; 23+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-09-02 16:47 UTC (permalink / raw)
To: Rene Rebe, kernel; +Cc: linux-kernel, sparclinux, andreas, anthony.yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara
2025-09-02 16:47 ` John Paul Adrian Glaubitz
@ 2025-09-02 16:51 ` Rene Rebe
2025-09-02 16:53 ` John Paul Adrian Glaubitz
0 siblings, 1 reply; 23+ messages in thread
From: Rene Rebe @ 2025-09-02 16:51 UTC (permalink / raw)
To: glaubitz; +Cc: kernel, linux-kernel, sparclinux, andreas, anthony.yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara
2025-09-02 16:51 ` Rene Rebe
@ 2025-09-02 16:53 ` John Paul Adrian Glaubitz
2025-09-02 17:04 ` Rene Rebe
2025-09-02 21:51 ` René Rebe
0 siblings, 2 replies; 23+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-09-02 16:53 UTC (permalink / raw)
To: Rene Rebe; +Cc: kernel, linux-kernel, sparclinux, andreas, anthony.yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara
2025-09-02 16:53 ` John Paul Adrian Glaubitz
@ 2025-09-02 17:04 ` Rene Rebe
2025-09-02 17:11 ` John Paul Adrian Glaubitz
2025-09-02 21:51 ` René Rebe
1 sibling, 1 reply; 23+ messages in thread
From: Rene Rebe @ 2025-09-02 17:04 UTC (permalink / raw)
To: glaubitz; +Cc: kernel, linux-kernel, sparclinux, andreas, anthony.yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara
2025-09-02 17:04 ` Rene Rebe
@ 2025-09-02 17:11 ` John Paul Adrian Glaubitz
0 siblings, 0 replies; 23+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-09-02 17:11 UTC (permalink / raw)
To: Rene Rebe; +Cc: kernel, linux-kernel, sparclinux, andreas, anthony.yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara
2025-09-02 16:53 ` John Paul Adrian Glaubitz
2025-09-02 17:04 ` Rene Rebe
@ 2025-09-02 21:51 ` René Rebe
1 sibling, 0 replies; 23+ messages in thread
From: René Rebe @ 2025-09-02 21:51 UTC (permalink / raw)
To: John Paul Adrian Glaubitz
Cc: Rene Rebe, kernel, linux-kernel, sparclinux, andreas,
anthony.yznaga
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
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2025-09-02 21:51 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-26 16:03 Fix accurate exception reporting in SPARC assembly Michael Karcher
2025-08-26 16:03 ` [PATCH 1/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC Michael Karcher
2025-08-29 10:53 ` John Paul Adrian Glaubitz
2025-09-02 16:33 ` Rene Rebe
2025-08-26 16:03 ` [PATCH 2/4] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III Michael Karcher
2025-08-27 6:34 ` John Paul Adrian Glaubitz
2025-08-28 15:53 ` John Paul Adrian Glaubitz
2025-08-30 1:57 ` Anthony Yznaga
2025-08-30 8:35 ` Michael Karcher
2025-09-02 16:38 ` Rene Rebe
2025-08-26 16:03 ` [PATCH 3/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara Michael Karcher
2025-08-29 21:44 ` John Paul Adrian Glaubitz
2025-09-02 16:40 ` Rene Rebe
2025-09-02 16:47 ` John Paul Adrian Glaubitz
2025-09-02 16:51 ` Rene Rebe
2025-09-02 16:53 ` John Paul Adrian Glaubitz
2025-09-02 17:04 ` Rene Rebe
2025-09-02 17:11 ` John Paul Adrian Glaubitz
2025-09-02 21:51 ` René Rebe
2025-08-26 16:03 ` [PATCH 4/4] sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara 4 Michael Karcher
2025-08-27 6:37 ` John Paul Adrian Glaubitz
2025-08-28 20:21 ` John Paul Adrian Glaubitz
2025-08-29 13:24 ` Michael Karcher
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).