Re: [PATCH v2 20/22] selftests: futex: Test sys_futex_waitv() timeout
From: Adhemerval Zanella <hidden>
Date: 2021-11-09 13:01:08
Also in:
lkml
On 09/11/2021 09:52, André Almeida via Libc-alpha wrote:
Hi Vasily, Às 08:18 de 09/11/21, Vasily Gorbik escreveu:quoted
On Thu, Sep 23, 2021 at 02:11:09PM -0300, André Almeida wrote:quoted
Test if the futex_waitv timeout is working as expected, using the supported clockid options.quoted
+ /* futex_waitv with CLOCK_MONOTONIC */ + if (futex_get_abs_timeout(CLOCK_MONOTONIC, &to, timeout_ns)) + return RET_FAIL; + res = futex_waitv(&waitv, 1, 0, &to, CLOCK_MONOTONIC); + test_timeout(res, &ret, "futex_waitv monotonic", ETIMEDOUT); + + /* futex_waitv with CLOCK_REALTIME */ + if (futex_get_abs_timeout(CLOCK_REALTIME, &to, timeout_ns)) + return RET_FAIL; + res = futex_waitv(&waitv, 1, 0, &to, CLOCK_REALTIME); + test_timeout(res, &ret, "futex_waitv realtime", ETIMEDOUT);Hi André, when built with -m32 and run as compat this two futex_waitv calls hang on x86 and s390 (noticed while wiring up futex_waitv). The rest of the futex selftests pass. This suggests some common compat issue? Any ideas?The issue is that futex_waitv() only accepts struct timespec that uses 64bit members. When using -m32, glibc will give you a 32bit timespec, thus the timeout won't wort. Someday glibc will provide 64bit timespec to 32bit userspace, given that this is affected by y2038 bug.
We do since glibc 2.34, but you need to opt-in by defining -D_TIME_SIZE=64. The default might change in a future release, so hopefully we will have both LFS and 64-bit as the default ABI.
In previous submissions I added a workaround for that in the selftest[0]. Search for "Y2038 section for 32-bit applications" in that link. I'll submit something like that for futex_waitv() timeout test. [0] https://lore.kernel.org/lkml/20210709001328.329716-6-andrealmeid@collabora.com/ (local)