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;
Date:   Mon, 29 Mar 2021 11:16:48 +0200
From:   Miroslav Lichvar <mlichvar@redhat.com>
To:     Richard Cochran <richardcochran@gmail.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Daphne Preston-Kendall <dpk@nonceword.org>,
        LKML <linux-kernel@vger.kernel.org>,
        John Stultz <john.stultz@linaro.org>,
        "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Subject: Re: [Bug 212265] New: clock_gettime(CLOCK_TAI, ...) should return an
 error when TAI has not been configured
Message-ID: <YGGbAIoCKDbZLQQ0@localhost>
References: <87sg4iupzs.fsf@nanos.tec.linutronix.de>
 <20210327032859.GA3168@hoboy.vegasvil.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210327032859.GA3168@hoboy.vegasvil.org>
Precedence: bulk

On 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.

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.

> 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.

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. 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.

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.

-- 
Miroslav Lichvar