Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Subject: Re: [musl] Question about musl's time() implementation in time.c
From:   Adhemerval Zanella <adhemerval.zanella@linaro.org>
In-Reply-To: <CAK8P3a3WZB81QqAJF1zi0Lp0n2vKhjKhiCS4vcOoVi8jt-Y3aA@mail.gmail.com>
Date:   Wed, 15 Jun 2022 09:55:04 -0700
Cc:     musl@lists.openwall.com, John Stultz <jstultz@google.com>,
        Stephen Boyd <sboyd@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>
Content-Transfer-Encoding: quoted-printable
Message-Id: <929C8485-D7F2-470A-B704-8068540DC358@linaro.org>
References: <CAFJhRnoEifeo0Tr2qfKD031C=9jYZ7oP3zSR9hFUmFp86Og7+Q@mail.gmail.com>
 <CAK8P3a1RVKLFT0aX38fJoFejgrq7VCz7auHjtsBB9W0rwnedCw@mail.gmail.com>
 <20220607163053.GD7074@brightrain.aerifal.cx>
 <CAFJhRnrWPC6pk67Xo9A9EeHFhoJCkE2PfwS4wFUep2JS3D9ujQ@mail.gmail.com>
 <CAK8P3a04TcLnhEE+MmQGOLU_AcVD5Rb+8vCKFSRF-zg33161ig@mail.gmail.com>
 <20220614170013.GH7074@brightrain.aerifal.cx>
 <CAK8P3a0d9hOuv+RiN_eQZtmfc7DCbJe6nEhL+W1AU2kFjiDZWw@mail.gmail.com>
 <20220614204900.GI7074@brightrain.aerifal.cx>
 <CAK8P3a0jk736rPueff--Uor=tHmicHZgoikrAsjp0DHxmkaiWg@mail.gmail.com>
 <20220614232826.GJ7074@brightrain.aerifal.cx>
 <CAK8P3a3WZB81QqAJF1zi0Lp0n2vKhjKhiCS4vcOoVi8jt-Y3aA@mail.gmail.com>
To:     Arnd Bergmann <arnd@kernel.org>
Precedence: bulk


> On 15 Jun 2022, at 05:09, Arnd Bergmann <arnd@kernel.org> wrote:
>=20
> On Wed, Jun 15, 2022 at 1:28 AM Rich Felker <dalias@libc.org> wrote:
>> On Tue, Jun 14, 2022 at 11:11:32PM +0200, Arnd Bergmann wrote:
>>>=20
>>> The thing is that a lot of file systems would still behave the same =
way
>>> because they round times down to a filesystem specific resolution,
>>> often one microsecond or one second, while the kernel time =
accounting
>>> is in nanoseconds. There have been discussions about an interface
>>> to find out what the actual resolution on a given mount point is =
(similar
>>> to clock_getres), but that never made it in. The guarantees that you
>>> get from file systems at the moment are:
>>=20
>> It's normal that they may be rounded down the the filesystem =
timestamp
>> granularity. I thought what was going on here was worse.
>=20
> It gets rounded down twice: first down to the start of the current
> timer tick, which is at an arbitrary nanosecond value in the past =
10ms,
> and then to the resolution of the file system. The result is that the
> file timestamp can point to a slightly earlier value, up to max(timer =
tick
> cycle, fs resolution) before the actual nanosecond value. We don't
> advertise the granule of the file system though, so I would expect
> this to be within the expected behavior.
>=20
>> OK, the time syscall doing the wrong thing here (using a different
>> clock that's not correctly ordered with respect to CLOCK_REALTIME)
>> seems to be the worst problem here -- if I'm understanding it right.
>> The filesystem issue might be a non-issue if it's truly equivalent to
>> just having coarser fs timestamp granularity, which is allowed.
>=20
> Adding the kernel timekeeping maintainers to Cc. I think this is a
> reasonable argument, but it goes against the current behavior.
>=20
> We have four implementations of the time() syscall that one would
> commonly encounter:
>=20
> - The kernel syscall, using (effectively) CLOCK_REALTIME_COARSE
> - The kernel vdso, using (effectively) CLOCK_REALTIME_COARSE
> - The glibc interface, calling =
__clock_gettime64(CLOCK_REALTIME_COARSE, ...)
> - The musl interface, calling __clock_gettime64(CLOCK_REALTIME, ...)
>=20
> So even if everyone agrees that the musl implementation is the
> correct one, I think both linux and glibc are more likely to stick =
with
> the traditional behavior to avoid breaking user space code such as the
> libc-test case that Zev brought up initially. At least Adhemerval's
> time() implementation in glibc[1] appears to have done this =
intentionally,
> while the Linux implementation has simply never changed this in an
> incompatible way since Linux-0.01 added time() and 0.99.13k added
> the high-resolution gettimeofday().
>=20
>       Arnd
>=20
> [1] https://sourceware.org/git/?p=3Dglibc.git;a=3Dcommitdiff;h=3D0d56378=
349

Indeed I have changed glibc to be consistent on all architectures to =
mimic kernel
behavior time syscall and avoid this very issue. We did not have a =
consistent
implementation before, so glibc varied depending of architecture and =
kernel
version whether it uses CLOCK_REALTIME or CLOCK_REALTIME_COARSE.

If kernel does change to make time() use CLOCK_REALTIME, it would make
sense to make glibc __clock_gettime64 to use it as well. We will also =
need to
either disable time vDSO usage on x86 and powerpc or make kernel =
implementation=09
to use CLOCK_REALTIME as well.