All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	linux-arm-kernel@lists.infradead.org, y2038@lists.linaro.org
Subject: Re: [Y2038] Re: RTC hctosys disabled for 32-bit systems
Date: Thu, 1 Sep 2022 17:02:51 +0100	[thread overview]
Message-ID: <YxDXqxkf7ONHOWSU@shell.armlinux.org.uk> (raw)
In-Reply-To: <511f86d8-eadf-40ba-9f0c-022cc4d251fb@www.fastmail.com>

On Thu, Sep 01, 2022 at 05:48:01PM +0200, Arnd Bergmann wrote:
> On Thu, Sep 1, 2022, at 3:46 PM, Russell King (Oracle) wrote:
> > On Thu, Sep 01, 2022 at 03:12:57PM +0200, Arnd Bergmann wrote:
> >> Ah, I forgot that systemd actually needs it. So I guess there is
> >> currently no way to use systemd on 32-bit machines that are
> >> meant to survive 2038, regardless of whether systemd and glibc are
> >> built with a 64-bit time_t or not, right?
> >> 
> >> Is there perhaps a way to change the logic in a way that
> >> it does not depend on the current time but instead depends
> >> on a property of the RTC device itself, so we make systems
> >> break immediately instead of by surprise in 2038?
> >
> > Are you seriously suggesting to cause regressions on systems where
> > the RTC can send the kernel's timekeeping back to the early 1900s,
> > rather than printing a big fat warning message in the kernel log?
> 
> I think the systems that can send the timekeeping back into the early
> 1900s (or at least after 1970) are fine, the problem is the systems
> that can randomly send the timekeeping into the post-2038 future.

I believe Armada 388 systems can do that - and since Armada 388 systems
are involved in my connectivity, I would very much prefer it if someone
doesn't patch stuff that causes them to explode when I decide to
upgrade the kernel.

(Yes, I've run into the broken systemd issue with them when the RTC
was not correctly set on platform delivery.)

> What kind of warning would you suggest to print here? I don't see
> how warning about broken hardware at every boot would help, since
> there is no way for users to react to that warning. Similarly,
> warning about a time_t value past 2038 does not help because
> at that time one either has a bricked system (if using a systemd
> with 32-bit time_t)  or it is actually 2038 and the system
> reverts back to 1970.
> 
> What might work is to have all drivers for broken RTC devices
> default to a 1902-2037 (or 1970-2037) date range to ensure
> that only those devices are broken in 2038, but still allow
> overriding the "start-year" property in DT for machines that
> don't use the broken systemd.

I don't care too much how it's handled, but my objection is purely
against the intentional breaking of platforms such that they cause
people pain.

Sure, they will break in 2038, but that's no reason to break them
in 2022/3.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-09-01 16:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-01 11:31 RTC hctosys disabled for 32-bit systems Reinier Kuipers
2022-09-01 11:55 ` Arnd Bergmann
2022-09-01 12:49   ` Alexandre Belloni
2022-09-01 13:12     ` Arnd Bergmann
2022-09-01 13:46       ` Russell King (Oracle)
2022-09-01 15:48         ` [Y2038] " Arnd Bergmann
2022-09-01 16:02           ` Russell King (Oracle) [this message]
2022-09-01 20:33             ` Arnd Bergmann
2022-09-01 21:11               ` Alexandre Belloni
2022-09-02 15:24                 ` Arnd Bergmann
2022-09-01 13:57       ` Alexandre Belloni
2022-09-01 15:29         ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YxDXqxkf7ONHOWSU@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=alexandre.belloni@bootlin.com \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=y2038@lists.linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.