[PATCH] riscv: uapi: Lie about having futex()

[PATCH] riscv: uapi: Lie about having futex()

[Palmer Dabbelt]

Without this libstdc++ correctly detects the lack of a futex() syscall
on rv32 and uses a fallback that doesn't work because it depends on
64-bit atomics.

Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

---
I'm not exactly sure why this is triggering now, as it seems like all
the conditions have been there for a while, but I had to swizzle around
the toolchain tuples recently due to some glibc build system
improvements and I suspect it's related.

It looks viable to update libstdc++ to understand futex_time64, but
given how common SYS_futex is these days I'm guessing some other bits of
userspace will end up broken as well.   This certainly feels dirty, but
it's easy.
---
 arch/riscv/include/asm/unistd.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/riscv/include/asm/unistd.h b/arch/riscv/include/asm/unistd.h
index 221630bdbd07..26116686690a 100644
--- a/arch/riscv/include/asm/unistd.h
+++ b/arch/riscv/include/asm/unistd.h
@@ -24,3 +24,11 @@
 #include <uapi/asm/unistd.h>
 
 #define NR_syscalls (__NR_syscalls)
+
+/*
+ * Userspace (at least libstdc++) has come to expect SYS_futex, but we only
+ * have SYS_futex_time64 on rv32.  So just lie.
+ */
+#ifndef __LP64__
+#define __NR_futex __NR_futex_time64
+#endif
-- 
2.39.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] riscv: uapi: Lie about having futex()

[Andreas Schwab]

On Jan 19 2023, Palmer Dabbelt wrote:

> diff --git a/arch/riscv/include/asm/unistd.h b/arch/riscv/include/asm/unistd.h
> index 221630bdbd07..26116686690a 100644
> --- a/arch/riscv/include/asm/unistd.h
> +++ b/arch/riscv/include/asm/unistd.h
> @@ -24,3 +24,11 @@
>  #include <uapi/asm/unistd.h>
>  
>  #define NR_syscalls (__NR_syscalls)
> +
> +/*
> + * Userspace (at least libstdc++) has come to expect SYS_futex, but we only
> + * have SYS_futex_time64 on rv32.  So just lie.
> + */
> +#ifndef __LP64__
> +#define __NR_futex __NR_futex_time64
> +#endif

This is not a uapi file, so why does this have any influence on
libstdc++?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] riscv: uapi: Lie about having futex()

[Arnd Bergmann]

On Thu, Jan 19, 2023, at 20:39, Palmer Dabbelt wrote:
> Without this libstdc++ correctly detects the lack of a futex() syscall
> on rv32 and uses a fallback that doesn't work because it depends on
> 64-bit atomics.
>
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
>
> ---
> I'm not exactly sure why this is triggering now, as it seems like all
> the conditions have been there for a while, but I had to swizzle around
> the toolchain tuples recently due to some glibc build system
> improvements and I suspect it's related.
>
> It looks viable to update libstdc++ to understand futex_time64, but
> given how common SYS_futex is these days I'm guessing some other bits of
> userspace will end up broken as well.   This certainly feels dirty, but
> it's easy.

Aside from what Andreas said, this is just wrong, riscv definitely
does not have a futex syscall and redirecting it to a different
syscall will lead to worse bugs because of mismatched arguments.

One possibility that we had discussed in the past is to actually
add support for a subset of futex() in configurations without
CONFIG_COMPAT_32BIT, which would include all rv32 kernels.

To avoid having to define an ABI with the incompatible 32-bit
timespec, this partial futex call would either have to reject
all commands that take a timeout (FUTEX_WAIT, FUTEX_LOCK_PI,
FUTEX_LOCK_PI2, FUTEX_WAIT_BITSET, FUTEX_WAIT_REQUEUE_PI) or
reject those calls that set a non-NULL timeout pointer.

I'm not convinced that this would actually be better than
what we have today though: right now any application that
tries to use futex_time32 but does not know futex_time64
will fail to build on riscv32.  If we provide a __NR_futex,
then all of these will build, but anything that actually
uses a timeout will receive -ENOSYS or similar and break
at runtime.

      Arnd

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv