[PATCH 0/3] s390: Fix and improve inline assembly constraints

[PATCH 0/3] s390: Fix and improve inline assembly constraints

[Heiko Carstens]

While looking at xor_xc_2() I realized that its inline assembly constraints
are incorrect. Also the inline assembly constraints for the other xor()
function look incorrect, but are not (execute instruction vs register
zero). However that revealed another real bug on __stackleak_poison() with
another incorrect inline assembly constraint.

Fix and improve all of them.

Heiko Carstens (3):
  s390/xor: Fix xor_xc_2() inline assembly constraints
  s390/xor: Improve inline assembly constraints
  s390/stackleak: Fix __stackleak_poison() inline assembly constraint

 arch/s390/include/asm/processor.h |  2 +-
 arch/s390/lib/xor.c               | 10 +++++-----
 2 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.51.0

[PATCH 1/3] s390/xor: Fix xor_xc_2() inline assembly constraints

[Heiko Carstens]

The inline assembly constraints for xor_xc_2() are incorrect. "bytes",
"p1", and "p2" are input operands, while all three of them are modified
within the inline assembly. Given that the function consists only of this
inline assembly it seems unlikely that this may cause any problems, however
fix this in any case.

Fixes: 2cfc5f9ce7f5 ("s390/xor: optimized xor routing using the XC instruction")
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
---
 arch/s390/lib/xor.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/s390/lib/xor.c b/arch/s390/lib/xor.c
index 1721b73b7803..d703c44d5fd6 100644
--- a/arch/s390/lib/xor.c
+++ b/arch/s390/lib/xor.c
@@ -28,8 +28,8 @@ static void xor_xc_2(unsigned long bytes, unsigned long * __restrict p1,
 		"	j	3f\n"
 		"2:	xc	0(1,%1),0(%2)\n"
 		"3:"
-		: : "d" (bytes), "a" (p1), "a" (p2)
-		: "0", "cc", "memory");
+		: "+d" (bytes), "+a" (p1), "+a" (p2)
+		: : "0", "cc", "memory");
 }
 
 static void xor_xc_3(unsigned long bytes, unsigned long * __restrict p1,
-- 
2.51.0

Re: [PATCH 1/3] s390/xor: Fix xor_xc_2() inline assembly constraints

[Vasily Gorbik]

On Mon, Mar 02, 2026 at 02:34:58PM +0100, Heiko Carstens wrote:
> The inline assembly constraints for xor_xc_2() are incorrect. "bytes",
> "p1", and "p2" are input operands, while all three of them are modified
> within the inline assembly. Given that the function consists only of this
> inline assembly it seems unlikely that this may cause any problems, however
> fix this in any case.
> 
> Fixes: 2cfc5f9ce7f5 ("s390/xor: optimized xor routing using the XC instruction")
> Cc: stable@vger.kernel.org
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> ---
>  arch/s390/lib/xor.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>

[PATCH 2/3] s390/xor: Improve inline assembly constraints

[Heiko Carstens]

The inline assembly constraint for the "bytes" operand is "d" for all xor()
inline assemblies. "d" means that any register from 0 to 15 can be used. If
the compiler would use register 0 then the exrl instruction would not or
the value of "bytes" into the executed instruction - resulting in an
incorrect result.

However all the xor() inline assemblies make hard-coded use of register 0,
and it is correctly listed in the clobber list, so that this cannot happen.

Given that this is quite subtle use the better "a" constraint, which
excludes register 0 from register allocation in any case.

Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
---
 arch/s390/lib/xor.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/s390/lib/xor.c b/arch/s390/lib/xor.c
index d703c44d5fd6..da134c7d89a6 100644
--- a/arch/s390/lib/xor.c
+++ b/arch/s390/lib/xor.c
@@ -28,7 +28,7 @@ static void xor_xc_2(unsigned long bytes, unsigned long * __restrict p1,
 		"	j	3f\n"
 		"2:	xc	0(1,%1),0(%2)\n"
 		"3:"
-		: "+d" (bytes), "+a" (p1), "+a" (p2)
+		: "+a" (bytes), "+a" (p1), "+a" (p2)
 		: : "0", "cc", "memory");
 }
 
@@ -54,7 +54,7 @@ static void xor_xc_3(unsigned long bytes, unsigned long * __restrict p1,
 		"2:	xc	0(1,%1),0(%2)\n"
 		"3:	xc	0(1,%1),0(%3)\n"
 		"4:"
-		: "+d" (bytes), "+a" (p1), "+a" (p2), "+a" (p3)
+		: "+a" (bytes), "+a" (p1), "+a" (p2), "+a" (p3)
 		: : "0", "cc", "memory");
 }
 
@@ -85,7 +85,7 @@ static void xor_xc_4(unsigned long bytes, unsigned long * __restrict p1,
 		"3:	xc	0(1,%1),0(%3)\n"
 		"4:	xc	0(1,%1),0(%4)\n"
 		"5:"
-		: "+d" (bytes), "+a" (p1), "+a" (p2), "+a" (p3), "+a" (p4)
+		: "+a" (bytes), "+a" (p1), "+a" (p2), "+a" (p3), "+a" (p4)
 		: : "0", "cc", "memory");
 }
 
@@ -122,7 +122,7 @@ static void xor_xc_5(unsigned long bytes, unsigned long * __restrict p1,
 		"4:	xc	0(1,%1),0(%4)\n"
 		"5:	xc	0(1,%1),0(%5)\n"
 		"6:"
-		: "+d" (bytes), "+a" (p1), "+a" (p2), "+a" (p3), "+a" (p4),
+		: "+a" (bytes), "+a" (p1), "+a" (p2), "+a" (p3), "+a" (p4),
 		  "+a" (p5)
 		: : "0", "cc", "memory");
 }
-- 
2.51.0

Re: [PATCH 2/3] s390/xor: Improve inline assembly constraints

[Vasily Gorbik]

On Mon, Mar 02, 2026 at 02:34:59PM +0100, Heiko Carstens wrote:
> The inline assembly constraint for the "bytes" operand is "d" for all xor()
> inline assemblies. "d" means that any register from 0 to 15 can be used. If
> the compiler would use register 0 then the exrl instruction would not or
> the value of "bytes" into the executed instruction - resulting in an
> incorrect result.
> 
> However all the xor() inline assemblies make hard-coded use of register 0,
> and it is correctly listed in the clobber list, so that this cannot happen.
> 
> Given that this is quite subtle use the better "a" constraint, which
> excludes register 0 from register allocation in any case.
> 
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> ---
>  arch/s390/lib/xor.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>

[PATCH 3/3] s390/stackleak: Fix __stackleak_poison() inline assembly constraint

[Heiko Carstens]

The __stackleak_poison() inline assembly comes with a "count" operand where
the "d" constraint is used. "count" is used with the exrl instruction and
"d" means that the compiler may allocate any register from 0 to 15.

If the compiler would allocate register 0 then the exrl instruction would
not or the value of "count" into the executed instruction - resulting in a
stackframe which is only partially poisoned.

Use the correct "a" constraint, which excludes register 0 from register
allocation.

Fixes: 2a405f6bb3a5 ("s390/stackleak: provide fast __stackleak_poison() implementation")
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
---
 arch/s390/include/asm/processor.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/include/asm/processor.h b/arch/s390/include/asm/processor.h
index cc187afa07b3..78195ee5e99f 100644
--- a/arch/s390/include/asm/processor.h
+++ b/arch/s390/include/asm/processor.h
@@ -159,7 +159,7 @@ static __always_inline void __stackleak_poison(unsigned long erase_low,
 		"	j	4f\n"
 		"3:	mvc	8(1,%[addr]),0(%[addr])\n"
 		"4:"
-		: [addr] "+&a" (erase_low), [count] "+&d" (count), [tmp] "=&a" (tmp)
+		: [addr] "+&a" (erase_low), [count] "+&a" (count), [tmp] "=&a" (tmp)
 		: [poison] "d" (poison)
 		: "memory", "cc"
 		);
-- 
2.51.0

Re: [PATCH 3/3] s390/stackleak: Fix __stackleak_poison() inline assembly constraint

[Vasily Gorbik]

On Mon, Mar 02, 2026 at 02:35:00PM +0100, Heiko Carstens wrote:
> The __stackleak_poison() inline assembly comes with a "count" operand where
> the "d" constraint is used. "count" is used with the exrl instruction and
> "d" means that the compiler may allocate any register from 0 to 15.
> 
> If the compiler would allocate register 0 then the exrl instruction would
> not or the value of "count" into the executed instruction - resulting in a
> stackframe which is only partially poisoned.
> 
> Use the correct "a" constraint, which excludes register 0 from register
> allocation.
> 
> Fixes: 2a405f6bb3a5 ("s390/stackleak: provide fast __stackleak_poison() implementation")
> Cc: stable@vger.kernel.org
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> ---
>  arch/s390/include/asm/processor.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>

Re: [PATCH 0/3] s390: Fix and improve inline assembly constraints

[Christoph Hellwig]

On Mon, Mar 02, 2026 at 02:34:57PM +0100, Heiko Carstens wrote:
> While looking at xor_xc_2() I realized that its inline assembly constraints
> are incorrect. Also the inline assembly constraints for the other xor()
> function look incorrect, but are not (execute instruction vs register
> zero). However that revealed another real bug on __stackleak_poison() with
> another incorrect inline assembly constraint.

No expert on the constraints, but have you considered to just convert
this code to pure assembly?

Otherwise please try to get it into Linus' tree ASAP so that I easily
rebase on that for the XOR series.

Re: [PATCH 0/3] s390: Fix and improve inline assembly constraints

[Heiko Carstens]

On Mon, Mar 02, 2026 at 02:47:51PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 02, 2026 at 02:34:57PM +0100, Heiko Carstens wrote:
> > While looking at xor_xc_2() I realized that its inline assembly constraints
> > are incorrect. Also the inline assembly constraints for the other xor()
> > function look incorrect, but are not (execute instruction vs register
> > zero). However that revealed another real bug on __stackleak_poison() with
> > another incorrect inline assembly constraint.
> 
> No expert on the constraints, but have you considered to just convert
> this code to pure assembly?

In general I don't like pure assembly files, since they come without any
instrumentation. Of course you could (correctly) argue that's the case for the
current inline assembly as well (except for ftrace). However the rest can be
easily fixed/addressed.

But I don't want to rush in even more code to make your life more complicated.

> Otherwise please try to get it into Linus' tree ASAP so that I easily
> rebase on that for the XOR series.

Sure, that should happen before rc3 comes out.

Re: [PATCH 0/3] s390: Fix and improve inline assembly constraints

[Vasily Gorbik]

On Mon, Mar 02, 2026 at 02:34:57PM +0100, Heiko Carstens wrote:
> While looking at xor_xc_2() I realized that its inline assembly constraints
> are incorrect. Also the inline assembly constraints for the other xor()
> function look incorrect, but are not (execute instruction vs register
> zero). However that revealed another real bug on __stackleak_poison() with
> another incorrect inline assembly constraint.
> 
> Fix and improve all of them.
> 
> Heiko Carstens (3):
>   s390/xor: Fix xor_xc_2() inline assembly constraints
>   s390/xor: Improve inline assembly constraints
>   s390/stackleak: Fix __stackleak_poison() inline assembly constraint
> 
>  arch/s390/include/asm/processor.h |  2 +-
>  arch/s390/lib/xor.c               | 10 +++++-----
>  2 files changed, 6 insertions(+), 6 deletions(-)

Applied, thank you!