Linux Kernel Selftest development
 help / color / mirror / Atom feed
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

  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