From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org, y2038@lists.linaro.org
Subject: Re: RTC hctosys disabled for 32-bit systems
Date: Thu, 1 Sep 2022 14:49:54 +0200 [thread overview]
Message-ID: <YxCqco98XvABPtaG@mail.local> (raw)
In-Reply-To: <802ca9c8-4b61-4568-a946-8e6330807eb3@www.fastmail.com>
On 01/09/2022 13:55:19+0200, Arnd Bergmann wrote:
> On Thu, Sep 1, 2022, at 1:31 PM, Reinier Kuipers wrote:
> >
> > I'm working to fix the y2038 issue for an existing sama5d3-based
> > product. This involves updating the kernel and glibc to appropriate
> > versions (5.10 and 2.35.1 respectively) and I got things running up to
> > a state where, from userspace, both date and hwclock commands have no
> > issue accepting dates beyond 2038. However, even with the RTC_HCTOSYS
> > and RTC_HCTOSYS_DEVICE options configured correctly, the RTC driver
> > fails to initialize the system clock at bootup.
> >
> > Some digging in rtc/class.c::rtc_hctosys() indicates that
> > do_settimeofday64() is deliberately not executed on systems with
> > BITS_PER_LONG==32 and a second counter higher than INT_MAX. I assumed
> > that the work on 64-bits timestamps was already fully implemented for
> > 32-bit systems as well, so my gut feel is that this
> > BITS_PER_LONG/INT_MAX check has become unnecessary. A test build with
> > these checks disabled results in correct time initialization at bootup
> > with, at a glance, no adverse effects. Does anybody here know whether
> > do_settimeofday64() is robust on 32-bit systems or that the checks
> > are still required to prevent further breakage?
>
> Please see commit b3a5ac42ab18 ("rtc: hctosys: Ensure system time
> doesn't overflow time_t") and https://github.com/systemd/systemd/issues/1143
> for the problem that originally caused this to be added.
>
> Removing this check would probably break systemd again for machines
> that return a post-y2038 time with systemd built on 32-bit time_t.
>
> The only reliable fix I can see would be to disable
> CONFIG_RTC_HCTOSYS_DEVICE. I think this is Alexandre's plan
> for the long run anyway, but I don't know if there has been any
> progress in convincing distros to turn it off.
>
This is still my plan but systemd mandates RTC_HCTOSYS and I couldn't
convince Lennart otherwise.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-09-01 12:51 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 [this message]
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)
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=YxCqco98XvABPtaG@mail.local \
--to=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.