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)