This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 01/12] linux: Fix vDSO macros build with time64 interfaces
On 13/12/2019 11:49, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>> But I think essentially what you are suggesting is an optimization to a
>> scenario that in practice should be unusual: a glibc build with a v5.1+
>> kernel headers, but deployed in a older kernel without time64 support.
>
> I don't think that's quite right. It will affect any future Fedora
> release that is deployed on current container environments, irrespective
> of container technology. In the past, vendors were really slow to
> rebase kernels.
If this scenario is indeed something usual for new glibc installations,
a generic build to enable both time64 and time support will eventually
require some probing to get kernel support.
>
> Furthermore, I think we have tentative agreement that we want to move to
> built-in system call tables to make it clearer what functionality we
> support. In particular, we viewed this as a requirement for rseq
> support. While it seems unlikely at this point that rseq support will
> make it into the upcoming release, I still hope to contribute my syscall
> tables patch next week. (The patch is done, but the auto-updating of
> the tables doesn't quite work yet the way Joseph would like it.)
>
> It's also not just an optimization because the selection logic should be
> generic and could be written once because it does not depend on the
> function pointer.
Even with syscall tables being update with latest kernel releases, the
optimization I see that you are suggesting it to avoid probing on
every syscall.
>
> But unfortunately, probing the way I suggested will not work. It's
> incompatible with existing seccomp filters running on newer kernels
> because they will cause the syscall in the vDSO to fail with ENOSYS. So
> we still need a fallback path unfortunately. If I'm right, this
> invalidates a previous review comment of mine regarding the fallback
> path after INLINE_VSYSCALL.
The fallback after the vDSO is essentially because some vDSO implementation
does not issue the syscall itself, but rather return ENOSYS. If I recall
correctly it was the case for mips for some 3.1x version, I would expected
that this is behaviour an outlier and usual vDSO support it to call the
syscall.
And the fallback also work if seccomp triggers an ENOSYS all well. So
what I think it might an option for !__ASSUME_TIME64_SYSCALLS with
an optimization to avoid probing is:
int r == -1;
static int time64_support = 1;
if (atomic_load_relaxed (&time64_support) == 1)
{
#ifdef HAVE_CLOCK_GETTIME64_VSYSCALL
/* It assumes that vDSO will always fallback to syscall
for invalid timers. */
r = INLINE_VSYSCALL (clock_gettime64, 2, clock_id, tp);
#else
r = INLINE_SYSCALL_CALL (clock_gettime64, clock_id, tp);
#endif
if (r == ENOSYS)
{
atomic_store_relaxed (&time64_support, 0);
r = -1;
}
}
if (r == -1)
{
/* Fallback code that uses 32-bit support. */
struct timespec tp32;
# ifdef HAVE_CLOCK_GETTIME_VSYSCALL
/* Some vDSO implementation might not call the syscall for
invalid timers. */
r = INLINE_VSYSCALL (clock_gettime, 2, clock_id, &tp32);
# endif
if (r == -1)
r = INLINE_SYSCALL_CALL (clock_gettime, clock_id, &tp32);
if (r == 0)
*tp = valid_timespec_to_timespec64 (tp32);
}
return r;