Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAK8P3a0VxM1BkjY1D2FfHi6L-ho_NH3v3+gBu45EfpjLF5NU5w@mail.gmail.com>
 <CAHk-=wiO2CWONDBud4nxoPgUJN1JEewFWhHa5wAqY8G5rrTXRQ@mail.gmail.com> <20190814000622.GB20365@mit.edu>
In-Reply-To: <20190814000622.GB20365@mit.edu>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Wed, 14 Aug 2019 10:31:33 +0200
Message-ID: <CAK8P3a1CXRETxn6Gh_cOxM3rZ-wUwVDu-7=yEwjqOY=uEdC6OQ@mail.gmail.com>
Subject: Re: New kernel interface for sys_tz and timewarp?
To:     "Theodore Y. Ts'o" <tytso@mit.edu>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Arnd Bergmann <arnd@arndb.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        John Stultz <john.stultz@linaro.org>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        Stephen Boyd <sboyd@kernel.org>,
        Florian Weimer <fweimer@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Alistair Francis <alistair.francis@wdc.com>,
        GNU C Library <libc-alpha@sourceware.org>,
        Karel Zak <kzak@redhat.com>,
        Lennart Poettering <lennart@poettering.net>,
        OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Aug 14, 2019 at 2:06 AM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> On Tue, Aug 13, 2019 at 10:30:34AM -0700, Linus Torvalds wrote:
> >
> > I suspect the only actual _valid_ use in the kernel for a time zone
> > setting is likely for RTC clock setting, but even that isn't really
> > "global", as much as "per RTC".
>
> As I recall (and I may or may not have been original for the original
> sys_tz; it was many years ago, and my memories of 1992 are a bit
> fuzzy) the only reason why we added it was because x86 systems that
> were dual-booting with Windows had a RTC which ticked localtime, and
> originally, the system time was fetched from the RTC in early boot,
> and then when the timezone was set, the time would be warped so it
> would be correct.

I think this was the case from 1992 to commit 84e345e4e209 ("time,
Fix setting of hardware clock in NTP code") in 2013, when we started
taking the time warp into account during the periodic sync_cmos_clock()
call from kernel/time/ntp.c.

> Trying to use this for anything else is probably a bad idea, and in a
> world where we can have initrd's and reading the RTC gets done by
> userspace as opposed to kernel, it probably doesn't make any sence to
> keep it.

As Alexandre keeps pointing out, we really ought to do this from user
space, but in systemd today still relies on the kernel setting the
initial time using CONFIG_RTC_HCTOSYS, but this breaks e.g.
when the rtc driver itself is a loadable module.

From what I understand it would be easy for systemd to sync the
rtc to system time at boot and let distros disable CONFIG_RTC_HCTOSYS,
but it still has to do the initial settimeofday(NULL, tz) call to
ensure the correct offset is used for sync_hw_clock() in case
CONFIG_GENERIC_CMOS_UPDATE or CONFIG_RTC_SYSTOHC
are set (which they tend to be at the moment).

In the long run, a distro can decide to avoid this all, once these
bits come together:

- glibc stops passing the caller timezone argument to the kernel
- the distro kernel disables CONFIG_RTC_HCTOSYS,
  CONFIG_RTC_SYSTOHC  and CONFIG_GENERIC_CMOS_UPDATE
- systemd reads the RTC at boot and sets the system
  time according to the configuration in /etc/localtime and /etc/adjtime
- systemd, ntp or something else in user space takes care of the periodic
  rtc update, again taking configuration into account.

When someone mixes today's glibc/systemd/kernel with other
components past that migration, things can go wrong somewhat
annoying but non-fatal ways:
- Users that dual-boot with windows may have to force Windows
  to set the RTC to UTC mode rather than setting Linux to
  localtime.
- if neither the kernel not user space do the periodic RTC update,
  it may be out of sync and cause a larger time jump after the
  next boot time ntp synchronization

Creating a kernel interface for systemd to see or contol how the
11-minute update is done in the kernel would help part of that
transition.

      Arnd