Re: [PATCH] riscv/atomic: Fix sign extension for RV64I

[Palmer Dabbelt]

On Thu, 11 Jun 2020 11:32:35 PDT (-0700), nhuck@xxxxxxxxxx wrote:
> The argument passed to cmpxchg is not guaranteed to be sign
> extended, but lr.w sign extends on RV64I. This makes cmpxchg
> fail on clang built kernels when __old is negative.
>
> To fix this, we just cast __old to long which sign extends on
> RV64I. With this fix, clang built RISC-V kernels now boot.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/867
> Cc: clang-built-linux@xxxxxxxxxxxxxxxx
> Signed-off-by: Nathan Huckleberry <nhuck@xxxxxxxxxx>
> ---
>  arch/riscv/include/asm/cmpxchg.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/riscv/include/asm/cmpxchg.h b/arch/riscv/include/asm/cmpxchg.h
> index d969bab4a26b..262e5bbb2776 100644
> --- a/arch/riscv/include/asm/cmpxchg.h
> +++ b/arch/riscv/include/asm/cmpxchg.h
> @@ -179,7 +179,7 @@
>  			"	bnez %1, 0b\n"				\
>  			"1:\n"						\
>  			: "=&r" (__ret), "=&r" (__rc), "+A" (*__ptr)	\
> -			: "rJ" (__old), "rJ" (__new)			\
> +			: "rJ" ((long)__old), "rJ" (__new)		\
>  			: "memory");					\
>  		break;							\
>  	case 8:								\
> @@ -224,7 +224,7 @@
>  			RISCV_ACQUIRE_BARRIER				\
>  			"1:\n"						\
>  			: "=&r" (__ret), "=&r" (__rc), "+A" (*__ptr)	\
> -			: "rJ" (__old), "rJ" (__new)			\
> +			: "rJ" ((long)__old), "rJ" (__new)		\
>  			: "memory");					\
>  		break;							\
>  	case 8:								\
> @@ -270,7 +270,7 @@
>  			"	bnez %1, 0b\n"				\
>  			"1:\n"						\
>  			: "=&r" (__ret), "=&r" (__rc), "+A" (*__ptr)	\
> -			: "rJ" (__old), "rJ" (__new)			\
> +			: "rJ" ((long)__old), "rJ" (__new)		\
>  			: "memory");					\
>  		break;							\
>  	case 8:								\
> @@ -316,7 +316,7 @@
>  			"	fence rw, rw\n"				\
>  			"1:\n"						\
>  			: "=&r" (__ret), "=&r" (__rc), "+A" (*__ptr)	\
> -			: "rJ" (__old), "rJ" (__new)			\
> +			: "rJ" ((long)__old), "rJ" (__new)		\
>  			: "memory");					\
>  		break;							\
>  	case 8:								\

So we talked about this earlier, but just so everyone's one the same page: I
think this should be a compiler bug, but the spec doesn't define any of this
stuff well enough that it actually is.  I'm sort of inclined to make it a
compiler bug, but I'm not sure if that's still possible and it requires a lot
more work.  I'm writing up a bigger email, but it's been floating around for a
few days and I don't want to delay this on sorting out what our inline assembly
actually does.

I've put this on fixes.

Thanks!