[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0d9hOuv+RiN_eQZtmfc7DCbJe6nEhL+W1AU2kFjiDZWw@mail.gmail.com>
Date: Tue, 14 Jun 2022 22:37:25 +0200
From: Arnd Bergmann <arnd@...nel.org>
To: musl@...ts.openwall.com
Subject: Re: Question about musl's time() implementation in time.c
On Tue, Jun 14, 2022 at 7:00 PM Rich Felker <dalias@...c.org> wrote:
> On Tue, Jun 14, 2022 at 06:50:40PM +0200, Arnd Bergmann wrote:
> > The coarse time can be up to one timer tick behind, so reading
> > CLOCK_REALTIME first
> > can give you the exact second with a small nanosecond value, while the
> > utime will still
> > set the previous value.
> >
> > Can you change the test case to check if the later time is less than
> > clock_getres(CLOCK_REALTIME_COARSE, ...) behind?
>
> This seems like a bug that the kernel uses the wrong clock for setting
> file timestamps. It can result in seeing events out-of-order (exactly
> as described in this thread). This should really be fixed or at least
> made switchable so users who care can fix it.
I can't find any reference to what the correct clock is here,
are you sure that this is specified at all? The decision to use the coarse
time in the kernel is definitely intentional, as reading the hardware
clocksource can be expensive (depending on the hardware), and
changing the behavior would likely break applications that rely on
it being the coarse clock.
Arnd
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.
