This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH v2] Linux/Alpha: don't use timeval32 system calls.
- From: Arnd Bergmann <arnd at arndb dot de>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Joseph Myers <joseph at codesourcery dot com>, Florian Weimer <fweimer at redhat dot com>, Lukasz Majewski <lukma at denx dot de>, Alistair Francis <alistair23 at gmail dot com>, Stepan Golosunov <stepan at golosunov dot pp dot ru>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Richard Henderson <rth at twiddle dot net>
- Date: Wed, 28 Aug 2019 17:58:33 +0200
- Subject: Re: [RFC PATCH v2] Linux/Alpha: don't use timeval32 system calls.
- References: <20190828153043.23644-1-zackw@panix.com>
On Wed, Aug 28, 2019 at 5:30 PM Zack Weinberg <zackw@panix.com> wrote:
>
> * The patched glibc will NOT use system calls that involve 32-bit
> time_t to implement its compatibility symbols. This will make both
> our lives and the kernel maintainers' lives easier. The primary
> argument I've seen against it is that the kernel could warn about
> uses of the old system calls, helping people find old binaries that
> need to be recompiled. I think there are several other ways we
> could accomplish this, e.g. scripts to scan the filesystem for
> binaries with references to the old symbol versions, or issuing
> diagnostics ourselves.
Another possible issue is seccomp filtering for a known set of
syscalls. The kernel vdso just got reverted so it no longer falls
back to the clock_gettime64() syscall to implement the
clock_gettime() vdso call when that is unavailable, see
https://lwn.net/Articles/795128/
For the specific case of Alpha, all the time32 syscall
implementations are kept around in the kernel so far.
It would be nice to eventually remove them since they
are likely incorrect in some way, but it's really hard to
be sure that they are no longer used.
> * What they do do, when they encounter overflow, is saturate the
> overflowed "struct timeval"(s): tv_sec is set to INT32_MAX and
> tv_nsec is set to 999999. That means time stops advancing for
> programs with 32-bit time_t when they reach the deadline. That's
> obviously going to break stuff, but I think wrapping around is
> probably going to break _more_ stuff. I'd be interested to hear
> arguments against, if anyone has one.
I don't think it matters much. The kernel does saturation for
inode timestamps since file systems can have arbitrary limits
other than the 1902...2038 year range and you can have timestamps
in the future, but for system calls we don't do the saturation but assume
that anything relying on them is already broken when they overflow.
Arnd