Re: [PATCH v1] futex: Add compat_sys_futex_waitv for 32bit compatibility

From: André Almeida
Date: Wed Nov 29 2023 - 13:56:43 EST


Hi Wei,

Em 27/11/2023 09:15, Wei Gao escreveu:
On Thu, Nov 23, 2023 at 01:09:55PM -0300, André Almeida wrote:
[+CC Arnd]

Hi Wei,

Em 23/11/2023 02:31, Wei Gao escreveu:
From: wei gao <wegao@xxxxxxxx>

Current implementation lead LTP test case futex_waitv failed when compiled with
-m32. This patch add new compat_sys_futex_waitv to handle m32 mode syscall.

The failure reason is futex_waitv in m32 mode will deliver kernel with struct
old_timespec32 timeout, but this struct type can not directly used by current
sys_futex_waitv implementation.

The new function copy main logic of current sys_futex_waitv, just update parameter
type from "struct __kernel_timespec __user *" to "struct old_timespec32 __user *,"
and use get_old_timespec32 within the new function to get timeout value.


From, what I recall, we don't want to add new syscalls with old_timespec32,
giving that they will have a limited lifetime. Instead, userspace should be
able to come up with a 64-bit timespec implementation for -m32.

Thanks,
André

Just a comment, I have checked the glibc latest code but do not see any implemention(*.c) on
futex_waitv syscall. So normally you have to do syscall directly with __NR_futex_waitv from
userspace. So i guess glibc-side can not covert this struct correctly currently. Correct me if
any misunderstanding.


futex() has no syscall wrappers in glibc. Userspace needs to figure out everything by themselves, including which struct they should use, and I don't think that glibc does any conversion. If you create manually a timespec64 that works in -m32, and pass this to sycall(__NR_futex_waitv, ..., &timeout, ...), it should work correctly. You can read more about how glibc is planning to deal with this at [1]. Please let me know if now it's more clear :)

[1] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

Thanks
Wei Gao