Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Daphne Preston-Kendal <dpk@nonceword.org>
Mime-Version: 1.0 (1.0)
Subject: Re: [Bug 212265] New: clock_gettime(CLOCK_TAI, ...) should return an error when TAI has not been configured
Date:   Mon, 29 Mar 2021 11:56:31 +0200
Message-Id: <2505F20D-ED84-4B36-9504-8A8C756C992E@nonceword.org>
References: <YGGbAIoCKDbZLQQ0@localhost>
Cc:     Richard Cochran <richardcochran@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>,
        John Stultz <john.stultz@linaro.org>,
        "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
In-Reply-To: <YGGbAIoCKDbZLQQ0@localhost>
To:     Miroslav Lichvar <mlichvar@redhat.com>
Precedence: bulk

On 29 Mar 2021, at 11:16, Miroslav Lichvar <mlichvar@redhat.com> wrote:

> =EF=BB=BFOn Fri, Mar 26, 2021 at 08:28:59PM -0700, Richard Cochran wrote:
>> Using ntpd on Debian, the service will set the offset, but only after
>> synchronization with the upstream server has been established, and
>> this takes about five minutes, IIRC.
>=20
> With the iburst option it shouldn't take more than 10 seconds. There
> might be an issue wrt stepping the clock when the initial offset is
> large. In Fedora and derived distros using chrony by default the
> TAI-UTC offset should be set right on the first update of the clock as
> expected.

Yeah, I personally am not really concerned about the immediate post-boot env=
ironment. As long as it=E2=80=99s ready by the time userland services are st=
arting, I think most applications that need TAI will be satisfied.

>> Getting back to the original point of the kernel returning an error,
>> I don't see a need for this.  Applications that require correct leap
>> seconds can simply call adjtimex() and wait until the initial zero
>> value is changed by ntpd/etc to the correct offset.  That isn't
>> fundamentally harder than calling clock_gettime() and waiting until
>> the error would go away.
>=20
> There are at least two issues with handling a zero offset as a special
> value. One is that zero could potentially be a valid value in distant
> future.

Since even a single negative leap second was, until recently, considered (qu=
ite literally) astronomically unlikely, and even now (where the earth is spi=
nning faster than ever hitherto expected) the most likely scenario by far se=
ems to be that it=E2=80=99ll just be a longer wait than usual for the next p=
ositive leap second, I=E2=80=99d say minus 37 leap seconds is a prospect for=
 the very very distant future indeed. But in theory, yes.

> The other is that the kernel updates the offset when a leap
> second is inserted/deleted even if the original offset is zero, so
> checking for zero (in the kernel or an application) works only until
> the first leap second after boot.

This is a problem and definitely speaks for having a way to tell whether CLO=
CK_TAI has been set up at all.

> The kernel would need to set a flag that the offset was set. Returning
> an error in clock_gettime() until the offset is set sounds reasonable
> to me, but I have no idea how many of the existing applications it
> would break.

Given that CLOCK_TAI doesn=E2=80=99t exist except on Linux, any portable Uni=
x application is likely to have a fallback of some kind, though perhaps only=
 at compile time.

Daphne Preston-Kendal