From: "Arnd Bergmann" <arnd@arndb.de>
To: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>
Cc: "Andy Lutomirski" <luto@kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Vincenzo Frascino" <vincenzo.frascino@arm.com>,
shuah <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 04/10] selftests: vDSO: vdso_test_abi: Provide compatibility with 32-bit musl
Date: Tue, 11 Nov 2025 16:07:58 +0100 [thread overview]
Message-ID: <2976374e-dd64-48ce-9726-56d97e94323c@app.fastmail.com> (raw)
In-Reply-To: <20251111153707-0926c681-0b2a-4cc0-9074-acbe8a6371c2@linutronix.de>
On Tue, Nov 11, 2025, at 15:46, Thomas Weißschuh wrote:
> On Tue, Nov 11, 2025 at 03:19:00PM +0100, Arnd Bergmann wrote:
>> Since SYS_clock_getres itself is provided by the libc implementation,
>> I wouldn't trust that this actually means the same as __NR_clock_getres,
>> and it might be set to __NR_clock_getres_time64.
>
> Should that case not work anyways, as libc would also need to convert the
> parameters transparently?
Not sure, I certainly wouldn't expect all libc implementations to
do this the same way.
> But I'll switch it over to __NR instead.
Ok
>> >> If we are trying to validate the interface here, we should probably
>> >> call both if available. If we just want to know the result and
>> >> trust that both work correctly, I'd always use __NR_clock_getres_time64
>> >> on 32-bit systems and __NR_clock_getres on 64-bit systems.
>> >
>> > As these are vDSO and not timer selftests I think we trust the syscalls.
>> > But how do we detect a native 64-bit time system? The preprocessor builtins
>> > won't work as a 32-bit pointer system may use 64-bit time syscalls. I am not
>> > aware of the UAPI #define, beyond the absence of __NR_clock_getres_time64.
>>
>> I would just check __BITS_PER_LONG=32 and require a linux-5.6+ kernel
>> at runtime to ensure the 64-bit calls are available.
>
> That doesn't work for x32. It uses __BITS_PER_LONG but does not have
> __NR_clock_getres_time64.
Right. In C code, we can usually check for
'sizeof(time_t) > sizeof(__kernel_long_t)' to catch that case,
but that doesn't work as easily with the preprocessor.
A more complex setup using both compile-time and run-time fallbacks
would work, e.g.
static int
syscall_clock_getres_old(clockid_t clockid, struct timespec *res);
#ifdef __NR_clock_getres
struct __kernel_old_timespec ts_old;
ret = syscall(__NR_clock_getres, clockid, &ts_old);
if (ret)
return ret;
res->tv_sec = ts_old.sec;
res->tv_nsec = ts_old.tv_nsec;
return 0;
#else
return -ENOSYS;
#endif
}
static int
syscall_clock_getres_time64(clockid_t clockid, struct timespec *res);
#ifdef __NR_clock_getres_time64
struct __kernel_timespec ts_64;
ret = syscall(__NR_clock_getres_time64, clockid, &ts_64);
if (ret)
return ret;
res->tv_sec = ts_64.sec;
res->tv_nsec = ts_64.tv_nsec;
return 0;
#else
return -ENOSYS;
#endif
}
static int
syscall_clock_getres(clockid_t clockid, struct timespec *res)
{
ret = syscall_clock_getres_time64(clockid, res);
if (ret != -ENOSYS)
return ret;
return syscall_clock_getres_old(clockid, &ts_old);
}
but the simpler check falling back to the 'old' version
is probably sufficient.
Arnd
next prev parent reply other threads:[~2025-11-11 15:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-11 10:49 [PATCH 00/10] selftests: vDSO: Stop using libc types for vDSO calls Thomas Weißschuh
2025-11-11 10:49 ` [PATCH 01/10] Revert "selftests: vDSO: parse_vdso: Use UAPI headers instead of libc headers" Thomas Weißschuh
2025-11-11 10:49 ` [PATCH 02/10] selftests: vDSO: Introduce vdso_types.h Thomas Weißschuh
2025-11-11 12:45 ` Arnd Bergmann
2025-11-11 13:47 ` Thomas Weißschuh
2025-11-11 14:48 ` Thomas Weißschuh
2025-11-11 10:49 ` [PATCH 03/10] selftests: vDSO: vdso_test_abi: Use types from vdso_types.h Thomas Weißschuh
2025-11-11 10:49 ` [PATCH 04/10] selftests: vDSO: vdso_test_abi: Provide compatibility with 32-bit musl Thomas Weißschuh
2025-11-11 12:59 ` Arnd Bergmann
2025-11-11 13:55 ` Thomas Weißschuh
2025-11-11 14:19 ` Arnd Bergmann
2025-11-11 14:46 ` Thomas Weißschuh
2025-11-11 15:07 ` Arnd Bergmann [this message]
2025-11-11 15:50 ` Thomas Weißschuh
2025-11-11 16:28 ` Arnd Bergmann
2025-11-11 10:49 ` [PATCH 05/10] selftests: vDSO: vdso_test_gettimeofday: Remove nolibc checks Thomas Weißschuh
2025-11-11 10:49 ` [PATCH 06/10] selftests: vDSO: vdso_test_gettimeofday: Use types from vdso_types.h Thomas Weißschuh
2025-11-11 10:49 ` [PATCH 07/10] selftests: vDSO: vdso_test_correctness: Drop SYS_getcpu fallbacks Thomas Weißschuh
2025-11-11 10:49 ` [PATCH 08/10] selftests: vDSO: vdso_test_correctness: Use types from vdso_types.h Thomas Weißschuh
2025-11-11 10:49 ` [PATCH 09/10] selftests: vDSO: vdso_test_correctness: Provide compatibility with 32-bit musl Thomas Weißschuh
2025-11-11 10:49 ` [PATCH 10/10] selftests: vDSO: vdso_test_correctness: Use facilities from parse_vdso.c Thomas Weißschuh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2976374e-dd64-48ce-9726-56d97e94323c@app.fastmail.com \
--to=arnd@arndb.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=luto@kernel.org \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=thomas.weissschuh@linutronix.de \
--cc=vincenzo.frascino@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox