From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Einar Jón" <tolvupostur@gmail.com>, linux-rtc@vger.kernel.org
Subject: Re: [PATCH] rtc: class: Fix max epoch in rtc_hctosys on 32-bit systems
Date: Tue, 18 Feb 2025 16:40:57 +0100 [thread overview]
Message-ID: <20250218154057079fa7e0@mail.local> (raw)
In-Reply-To: <8163c8e0-58d6-44a9-a5a2-6478fe4b0ff8@app.fastmail.com>
On 18/02/2025 15:51:24+0100, Arnd Bergmann wrote:
> On Tue, Feb 18, 2025, at 14:30, Alexandre Belloni wrote:
> > On 18/02/2025 13:45:56+0100, Einar Jón wrote:
> >> Hello again
> >>
> >> On second thought, removing is too general.
> >> But it's still very much broken. Is there any reason why this was not
> >> merged?
> >> https://lore.kernel.org/all/c5e8ab50-aacb-4651-8893-a6dd9edcd155@app.fastmail.com/T/
> >>
> >> Any thoughts on how this should be handled?
> >
> > The first step is to convince Lennart that mandating RTC_HCTOSYS xwas a
> > bad idea, the second step is to let userspace set the time instead. The
> > kernel can't take the proper decision because it simply doesn't know
> > whether userspace is TIME64 ready or not.
>
> It's been seven years since the you added the workaround, and
> there are a few things that have changed in the meantime:
>
> - most distros that use systemd have stopped supporting
> 32-bit targets
> - most distros that still support 32-bit have moved to a
> 64-bit time_t
> - 2038 is only 13 years away instead of 20, adding to the
> urgency of having future-proof default behavior.
>
> I don't know how many 32-bit machines are affected by the bug
> where they return a random time, or if they are more or less
> common than in the past.
This is going to break some of the Marvell board that RMK uses because I
guess he is not updating his userspace.
Also, I'd note that OpenEmbedded switched to 64-bit time_t by default
just last year.
I'm not against removing the workaround but keeping it doesn't actually
break anyone, it is still possible to set the time properly from
userspace as it should be done anyway so I'm not sure about the urgency.
The impact is mostly about messages timestamp in the boot log, before
being able to run hwclock or any similar tool.
Or am I missing anything?
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2025-02-18 15:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-18 11:11 [PATCH] rtc: class: Fix max epoch in rtc_hctosys on 32-bit systems Einar Jon Gunnarsson
[not found] ` <CABhNV21ZptxH9d4NyPo1xivS0GAXNsoLMLpPSRAsT8h5CX9hDw@mail.gmail.com>
2025-02-18 13:28 ` Einar Jón
2025-02-18 13:30 ` Alexandre Belloni
2025-02-18 14:51 ` Arnd Bergmann
2025-02-18 15:40 ` Alexandre Belloni [this message]
2025-02-18 16:00 ` Einar Jón
2025-02-18 16:05 ` Arnd Bergmann
2025-02-18 16:39 ` Alexandre Belloni
2025-02-19 7:36 ` Einar Jón
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=20250218154057079fa7e0@mail.local \
--to=alexandre.belloni@bootlin.com \
--cc=arnd@arndb.de \
--cc=linux-rtc@vger.kernel.org \
--cc=tolvupostur@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox