* [PATCH] selftests/powerpc: Fix ptrace tm failure
@ 2018-10-22 21:16 ` Breno Leitao
0 siblings, 0 replies; 5+ messages in thread
From: Breno Leitao @ 2018-10-22 21:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikey, segher, gromero, stable, Breno Leitao
Test ptrace-tm-spd-gpr fails on current kernel (4.19) due to a segmentation
fault that happens on the child process prior to setting cptr[2] = 1. This
causes the parent process to wait forever at 'while (!pptr[2])' and the test to
be killed by the test harness framework by timeout, thus, failing.
The segmentation fault happens because of a inline assembly being
generated as:
0x10000355c <tm_spd_gpr+492> lfs f0, 0(0)
This is reading memory position 0x0 and causing the segmentation fault.
This code is being generated by ASM_LOAD_FPR_SINGLE_PRECISION(flt_4), where
flt_4 is passed to the inline assembly block as:
[flt_4] "r" (&d)
Since the inline assembly 'r' constraint means any GPR, gpr0 is being
chosen, thus causing this issue when issuing a Load Floating-Point Single
instruction.
This patch simply changes the constraint to 'b', which specify that this
register will be used as base, and r0 is not allowed to be used, avoiding
this issue.
Other than that, removing flt_2 register from the input operands, since it
is not used by the inline assembly code at all.
Cc: stable@vger.kernel.org
Signed-off-by: Breno Leitao <leitao@debian.org>
---
tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c
index 327fa943c7f3..dbdffa2e2c82 100644
--- a/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c
+++ b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c
@@ -67,8 +67,8 @@ void tm_spd_gpr(void)
"3: ;"
: [res] "=r" (result), [texasr] "=r" (texasr)
: [gpr_1]"i"(GPR_1), [gpr_2]"i"(GPR_2), [gpr_4]"i"(GPR_4),
- [sprn_texasr] "i" (SPRN_TEXASR), [flt_1] "r" (&a),
- [flt_2] "r" (&b), [flt_4] "r" (&d)
+ [sprn_texasr] "i" (SPRN_TEXASR), [flt_1] "b" (&a),
+ [flt_4] "b" (&d)
: "memory", "r5", "r6", "r7",
"r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15",
"r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",
--
2.19.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH] selftests/powerpc: Fix ptrace tm failure
@ 2018-10-22 21:16 ` Breno Leitao
0 siblings, 0 replies; 5+ messages in thread
From: Breno Leitao @ 2018-10-22 21:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Breno Leitao, mikey, stable, gromero
Test ptrace-tm-spd-gpr fails on current kernel (4.19) due to a segmentation
fault that happens on the child process prior to setting cptr[2] = 1. This
causes the parent process to wait forever at 'while (!pptr[2])' and the test to
be killed by the test harness framework by timeout, thus, failing.
The segmentation fault happens because of a inline assembly being
generated as:
0x10000355c <tm_spd_gpr+492> lfs f0, 0(0)
This is reading memory position 0x0 and causing the segmentation fault.
This code is being generated by ASM_LOAD_FPR_SINGLE_PRECISION(flt_4), where
flt_4 is passed to the inline assembly block as:
[flt_4] "r" (&d)
Since the inline assembly 'r' constraint means any GPR, gpr0 is being
chosen, thus causing this issue when issuing a Load Floating-Point Single
instruction.
This patch simply changes the constraint to 'b', which specify that this
register will be used as base, and r0 is not allowed to be used, avoiding
this issue.
Other than that, removing flt_2 register from the input operands, since it
is not used by the inline assembly code at all.
Cc: stable@vger.kernel.org
Signed-off-by: Breno Leitao <leitao@debian.org>
---
tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c
index 327fa943c7f3..dbdffa2e2c82 100644
--- a/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c
+++ b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c
@@ -67,8 +67,8 @@ void tm_spd_gpr(void)
"3: ;"
: [res] "=r" (result), [texasr] "=r" (texasr)
: [gpr_1]"i"(GPR_1), [gpr_2]"i"(GPR_2), [gpr_4]"i"(GPR_4),
- [sprn_texasr] "i" (SPRN_TEXASR), [flt_1] "r" (&a),
- [flt_2] "r" (&b), [flt_4] "r" (&d)
+ [sprn_texasr] "i" (SPRN_TEXASR), [flt_1] "b" (&a),
+ [flt_4] "b" (&d)
: "memory", "r5", "r6", "r7",
"r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15",
"r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",
--
2.19.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] selftests/powerpc: Fix ptrace tm failure
2018-10-22 21:16 ` Breno Leitao
@ 2018-10-23 17:00 ` Segher Boessenkool
-1 siblings, 0 replies; 5+ messages in thread
From: Segher Boessenkool @ 2018-10-23 17:00 UTC (permalink / raw)
To: Breno Leitao; +Cc: linuxppc-dev, mikey, gromero, stable
On Mon, Oct 22, 2018 at 06:16:26PM -0300, Breno Leitao wrote:
> Test ptrace-tm-spd-gpr fails on current kernel (4.19) due to a segmentation
> fault that happens on the child process prior to setting cptr[2] = 1. This
> causes the parent process to wait forever at 'while (!pptr[2])' and the test to
> be killed by the test harness framework by timeout, thus, failing.
>
> The segmentation fault happens because of a inline assembly being
> generated as:
>
> 0x10000355c <tm_spd_gpr+492> lfs f0, 0(0)
>
> This is reading memory position 0x0 and causing the segmentation fault.
>
> This code is being generated by ASM_LOAD_FPR_SINGLE_PRECISION(flt_4), where
> flt_4 is passed to the inline assembly block as:
>
> [flt_4] "r" (&d)
>
> Since the inline assembly 'r' constraint means any GPR, gpr0 is being
> chosen, thus causing this issue when issuing a Load Floating-Point Single
> instruction.
>
> This patch simply changes the constraint to 'b', which specify that this
> register will be used as base, and r0 is not allowed to be used, avoiding
> this issue.
>
> Other than that, removing flt_2 register from the input operands, since it
> is not used by the inline assembly code at all.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Breno Leitao <leitao@debian.org>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
Segher
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] selftests/powerpc: Fix ptrace tm failure
@ 2018-10-23 17:00 ` Segher Boessenkool
0 siblings, 0 replies; 5+ messages in thread
From: Segher Boessenkool @ 2018-10-23 17:00 UTC (permalink / raw)
To: Breno Leitao; +Cc: mikey, linuxppc-dev, stable, gromero
On Mon, Oct 22, 2018 at 06:16:26PM -0300, Breno Leitao wrote:
> Test ptrace-tm-spd-gpr fails on current kernel (4.19) due to a segmentation
> fault that happens on the child process prior to setting cptr[2] = 1. This
> causes the parent process to wait forever at 'while (!pptr[2])' and the test to
> be killed by the test harness framework by timeout, thus, failing.
>
> The segmentation fault happens because of a inline assembly being
> generated as:
>
> 0x10000355c <tm_spd_gpr+492> lfs f0, 0(0)
>
> This is reading memory position 0x0 and causing the segmentation fault.
>
> This code is being generated by ASM_LOAD_FPR_SINGLE_PRECISION(flt_4), where
> flt_4 is passed to the inline assembly block as:
>
> [flt_4] "r" (&d)
>
> Since the inline assembly 'r' constraint means any GPR, gpr0 is being
> chosen, thus causing this issue when issuing a Load Floating-Point Single
> instruction.
>
> This patch simply changes the constraint to 'b', which specify that this
> register will be used as base, and r0 is not allowed to be used, avoiding
> this issue.
>
> Other than that, removing flt_2 register from the input operands, since it
> is not used by the inline assembly code at all.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Breno Leitao <leitao@debian.org>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
Segher
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: selftests/powerpc: Fix ptrace tm failure
2018-10-22 21:16 ` Breno Leitao
(?)
(?)
@ 2018-10-31 5:42 ` Michael Ellerman
-1 siblings, 0 replies; 5+ messages in thread
From: Michael Ellerman @ 2018-10-31 5:42 UTC (permalink / raw)
To: Breno Leitao, linuxppc-dev; +Cc: Breno Leitao, mikey, stable, gromero
On Mon, 2018-10-22 at 21:16:26 UTC, Breno Leitao wrote:
> Test ptrace-tm-spd-gpr fails on current kernel (4.19) due to a segmentation
> fault that happens on the child process prior to setting cptr[2] = 1. This
> causes the parent process to wait forever at 'while (!pptr[2])' and the test to
> be killed by the test harness framework by timeout, thus, failing.
>
> The segmentation fault happens because of a inline assembly being
> generated as:
>
> 0x10000355c <tm_spd_gpr+492> lfs f0, 0(0)
>
> This is reading memory position 0x0 and causing the segmentation fault.
>
> This code is being generated by ASM_LOAD_FPR_SINGLE_PRECISION(flt_4), where
> flt_4 is passed to the inline assembly block as:
>
> [flt_4] "r" (&d)
>
> Since the inline assembly 'r' constraint means any GPR, gpr0 is being
> chosen, thus causing this issue when issuing a Load Floating-Point Single
> instruction.
>
> This patch simply changes the constraint to 'b', which specify that this
> register will be used as base, and r0 is not allowed to be used, avoiding
> this issue.
>
> Other than that, removing flt_2 register from the input operands, since it
> is not used by the inline assembly code at all.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Breno Leitao <leitao@debian.org>
> Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/48dc0ef19044bfb69193302fbe3a83
cheers
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-10-31 14:39 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-22 21:16 [PATCH] selftests/powerpc: Fix ptrace tm failure Breno Leitao
2018-10-22 21:16 ` Breno Leitao
2018-10-23 17:00 ` Segher Boessenkool
2018-10-23 17:00 ` Segher Boessenkool
2018-10-31 5:42 ` Michael Ellerman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.