[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 at 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