Messages in this thread | | | Date | Thu, 18 Jun 2020 14:43:20 -0700 (PDT) | Subject | Re: [PATCH] riscv/atomic: Fix sign extension for RV64I | From | Palmer Dabbelt <> |
| |
On Thu, 11 Jun 2020 11:32:35 PDT (-0700), nhuck@google.com 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@googlegroups.com > Signed-off-by: Nathan Huckleberry <nhuck@google.com> > --- > 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!
| |