Question about [PATCH] [RFC] rtc: y2038: remove broken RTC_HCTOSYS workaround

Question about [PATCH] [RFC] rtc: y2038: remove broken RTC_HCTOSYS workaround

[Leonard Anderweit]

Hi,

I found this patch [1] which is necessary for a project I'm currently
working on. I'm using phyboard-wega [2] with an am335 ARM SoC which I
want to make y2038 proof.
Is there any reason it was never accepted?

[1]https://lore.kernel.org/all/20220908115337.1604277-1-arnd@kernel.org/


[2]https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/ti/omap/am335x-wega-rdk.dts

Regards
Leonard

Re: Question about [PATCH] [RFC] rtc: y2038: remove broken RTC_HCTOSYS workaround

[Alexandre Belloni]

On 24/06/2024 11:41:41+0000, Leonard Anderweit wrote:
> Hi,
> 
> I found this patch [1] which is necessary for a project I'm currently
> working on. I'm using phyboard-wega [2] with an am335 ARM SoC which I
> want to make y2038 proof.
> Is there any reason it was never accepted?
> 

The systemd maintainer think the kernel is well placed to take a
decision it can't actually take so they won't fix a bug where systemd is
crashing when userspace is 32bit.

The whole situation is frustrating and honestly, nobody should use the
hctosys insanity anyway. Obviously systemd mandates its usage and this
is yet another topic on which they think the kernel is better placed to
take decisions that are actually userspace policy.

I've been arguing for a while and gave up.

> [1]https://lore.kernel.org/all/20220908115337.1604277-1-arnd@kernel.org/
> [2]https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/ti/omap/am335x-wega-rdk.dts
> 
> Regards
> Leonard

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: Question about [PATCH] [RFC] rtc: y2038: remove broken RTC_HCTOSYS workaround

[Arnd Bergmann]

On Fri, Jun 28, 2024, at 00:43, Alexandre Belloni wrote:
> On 24/06/2024 11:41:41+0000, Leonard Anderweit wrote:
>> Hi,
>> 
>> I found this patch [1] which is necessary for a project I'm currently
>> working on. I'm using phyboard-wega [2] with an am335 ARM SoC which I
>> want to make y2038 proof.
>> Is there any reason it was never accepted?

Sorry for not having replied earlier. I'm definitely interested
in helping to make this work better, having spent a lot of time
on the kernel side of the y2038 work.

Which combination of distro, libc and init system are you using
in your work?

Are you running with COMPAT_32BIT_TIME disabled? This is something
you probably want in order to better test for corner cases that
still use time32 kernel ABIs somewhere, but it still requires
adding a few more workarounds in libc and other userspace
sources.

> The systemd maintainer think the kernel is well placed to take a
> decision it can't actually take so they won't fix a bug where systemd is
> crashing when userspace is 32bit.
>
> The whole situation is frustrating and honestly, nobody should use the
> hctosys insanity anyway. Obviously systemd mandates its usage and this
> is yet another topic on which they think the kernel is better placed to
> take decisions that are actually userspace policy.
>
> I've been arguing for a while and gave up.

I thought that systemd had at least fix the bug where it would
crash when a random 64-bit time was set, so we could try again
with this patch and see what breaks?

An important difference now is that Debian is finally changing
to a time64 userspace, which both avoids the problem that
the broken rtc_hctosys() time truncation was trying to work
around (all times returned here are now valid) and it means
that there is a much higher incentive to actually make
a systemd based userland work past 2038.

      Arnd

Re: Question about [PATCH] [RFC] rtc: y2038: remove broken RTC_HCTOSYS workaround

[Stefan Müller-Klieser]

Am Freitag, dem 28.06.2024 um 08:01 +0200 schrieb Arnd Bergmann:
> On Fri, Jun 28, 2024, at 00:43, Alexandre Belloni wrote:
> > On 24/06/2024 11:41:41+0000, Leonard Anderweit wrote:
> > > Hi,
> > > 
> > > I found this patch [1] which is necessary for a project I'm currently
> > > working on. I'm using phyboard-wega [2] with an am335 ARM SoC which I
> > > want to make y2038 proof.
> > > Is there any reason it was never accepted?
> 
> Sorry for not having replied earlier. I'm definitely interested
> in helping to make this work better, having spent a lot of time
> on the kernel side of the y2038 work.
> 
> Which combination of distro, libc and init system are you using
> in your work?

We have a Yocto scarthgap with glibc 2.39 and systemd 255.4.

> 
> Are you running with COMPAT_32BIT_TIME disabled? This is something
> you probably want in order to better test for corner cases that
> still use time32 kernel ABIs somewhere, but it still requires
> adding a few more workarounds in libc and other userspace
> sources.

We wanted to, but this still keeps systemd from booting. We are
debugging this currently.

> 
> > The systemd maintainer think the kernel is well placed to take a
> > decision it can't actually take so they won't fix a bug where systemd is
> > crashing when userspace is 32bit.
> > 
> > The whole situation is frustrating and honestly, nobody should use the
> > hctosys insanity anyway. Obviously systemd mandates its usage and this
> > is yet another topic on which they think the kernel is better placed to
> > take decisions that are actually userspace policy.
> > 
> > I've been arguing for a while and gave up.
> 
> I thought that systemd had at least fix the bug where it would
> crash when a random 64-bit time was set, so we could try again
> with this patch and see what breaks?

With the patch and COMPAT_32BIT_TIME enabled, it seems to work,
at least our test cases do.

> 
> An important difference now is that Debian is finally changing
> to a time64 userspace, which both avoids the problem that
> the broken rtc_hctosys() time truncation was trying to work
> around (all times returned here are now valid) and it means
> that there is a much higher incentive to actually make
> a systemd based userland work past 2038.

Yocto also seems to have the basics in place and some sanity checks
available for scarthgap but as said, we cannot disable the 32 bit api.
Regards, Stefan

> 
>       Arnd
> 

Re: Question about [PATCH] [RFC] rtc: y2038: remove broken RTC_HCTOSYS workaround

[Arnd Bergmann]

On Fri, Jun 28, 2024, at 08:33, Stefan Müller-Klieser wrote:
> Am Freitag, dem 28.06.2024 um 08:01 +0200 schrieb Arnd Bergmann:
>> On Fri, Jun 28, 2024, at 00:43, Alexandre Belloni wrote:
>> > On 24/06/2024 11:41:41+0000, Leonard Anderweit wrote:
>> > > Hi,
>> > > 
>> > > I found this patch [1] which is necessary for a project I'm currently
>> > > working on. I'm using phyboard-wega [2] with an am335 ARM SoC which I
>> > > want to make y2038 proof.
>> > > Is there any reason it was never accepted?
>> 
>> Sorry for not having replied earlier. I'm definitely interested
>> in helping to make this work better, having spent a lot of time
>> on the kernel side of the y2038 work.
>> 
>> Which combination of distro, libc and init system are you using
>> in your work?
>
> We have a Yocto scarthgap with glibc 2.39 and systemd 255.4.

Ok

>> Are you running with COMPAT_32BIT_TIME disabled? This is something
>> you probably want in order to better test for corner cases that
>> still use time32 kernel ABIs somewhere, but it still requires
>> adding a few more workarounds in libc and other userspace
>> sources.
>
> We wanted to, but this still keeps systemd from booting. We are
> debugging this currently.

My guess is that this is still an issue with glibc still relying
on time32 system calls to be present. I have not looked at it
in a while, but the most common time32 syscall that everyone
relies on is futex(). With COMPAT_32BIT_TIME disabled, you
need to call futex_time64() instead even if there is a NULL
timeout. There may also be other time32 syscalls in use here.

The way I would debug this is to run a 32-bit scarthgap
userspace in a chroot on a 64-bit kernel with COMPAT_32BIT_TIME=n,
to see what kernel interfaces are missing while still being
able to run normal 64-bit debugging tools.
You can do this either on an arm64 or x86_64 host, whichever is
easier for you to get set up.

I don't see anything in systemd itself that relies on time32
syscalls, it does not appear to directly call futex or any
of the other ones, and the seccomp filters in there look like
they take time64 syscalls into account correctly.

       Arnd