[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220607163053.GD7074@brightrain.aerifal.cx>
Date: Tue, 7 Jun 2022 12:30:53 -0400
From: Rich Felker <dalias@...c.org>
To: Arnd Bergmann <arnd@...nel.org>
Cc: musl@...ts.openwall.com, Zev Levy Stevenson <zevlevys@...il.com>
Subject: Re: Question about musl's time() implementation in time.c
On Tue, Jun 07, 2022 at 04:29:28PM +0200, Arnd Bergmann wrote:
> On Tue, Jun 7, 2022 at 2:25 PM Zev Levy Stevenson <zevlevys@...il.com> wrote:
> >
> > Hi all,
> >
> > While running the libc-test test suite on a customized clang+musl
> > build, I had trouble with some of the tests because of issues with
> > time accuracy.
> > I can go in detail if needed, but the problem seemed to boil down
> > to the time() function in musl (in src/time/time.c) using a
> > clock_gettime syscall (without vdso) instead of using the Linux
> > time syscall that we expected it to use. Some other libc
> > implementations use this syscall, and indeed after switching the
> > syscall used in time () the tests passed, seemingly because the
> > accuracy of the clocks used matched up.
> > My main question is why musl's implementation doesn't use the time
> > syscall, I'd be happy to hear if there was a special reason for
> > this.
>
> The time() syscall on 32-bit architectures returns a 32-bit integer,
> which overflows in y2038, only
> clock_gettime() has the required range.
This is indeed a good reason it can't be changed. Historically, though
it was just a matter of avoiding code duplication. Due to the desire
to support vdso and, clock_gettime requires a good deal of logic to
find and use the vdso function and perform fallbacks if it's not
available, or if the newer syscalls are not available. If time() did
not use clock_gettime as its backend, but instead used separate kernel
interfaces, this logic would need to be duplicated in time() too. It
would also impose weird incentives for new archs to provide a time()
syscall or vdso function, or would impose a requirement that we *also*
duplicate the vdso logic to consume the vdso clock_gettime in time()
if there's no vdso time().
If you've created an alternate kernel/syscall implementation where
clock_gettime behaves badly and a legacy time syscall (or vdso
function?) behaves good, that really doesn't seem like a good
implementation choice. Especially if they produce mismatching output.
I guess you could make a stretch argument that the implementation
behaves as if someone is constantly changing the clock, but short of
that, think it's even nonconforming (there's a single realtime clock
and they're both supposed to return times in terms of it). Are there
reasons you're trying to do things that way?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
