Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Arnd Bergmann <arnd at arndb dot de>]

On Wed, Jun 26, 2019 at 11:07 AM Lukasz Majewski <lukma@denx.de> wrote:
> > On Tue, Jun 25, 2019 at 5:51 PM Lukasz Majewski <lukma@denx.de> wrote:
> > > > On Tue, Jun 25, 2019 at 2:11 AM Alistair Francis <alistair.francis@wdc.com> wrote:
> > This is problematic in the scenario that you have an embedded system
> > you deploy today, and turn off the time32 syscalls in the kernel.
>
> I assume that then we would only have __NR_clock_settime64 defined (no
> __NR_clock_settime available) on WORDSIZE==32 archs?

No, the kernel header files are generated independently of the configuration.
The macro would still be there at compile-time, but depending on kernel
configuration, the system call would return -ENOSYS, same way we do
for other optional system calls.

> > In 2038, it stops working because of the time_t overflow that was
> > not caught during validation. If we call the time32 interface here, it
> > breaks immediately on kernels that return -ENOSYS from
> > clock_gettime(),
>
> Maybe I'm not aware of something, but isn't the removal of
> clock_settime syscall supporting only 32 bit time (on archs with
> WORDSIZE==32) the ABI break?
>
> Shouldn't those syscalls be kept until the minimal supported glibc
> kernel version is 5.1?

We will probably keep them as an option in the kernel until 2038,
but leave it to the distro or embedded system design to turn them
on or off. Most of the remaining general-purpose distros (Ubuntu
just said they'd stop theirs, others are likely to follow) are likely to
leave them on for compatibility, while embedded systems with
projected life times beyond 2038 should turn them off.

The minimal kernel version supported by glibc doesn't matter
to the kernel, as kernels support older C libraries going back
to the beginning, just like newer glibc versions support
applications linked against earlier glibc versions.

> The latest patch for clock_settime [1]:
> Could be changed to:
>
> #if __TIMESIZE != 64
> int
> __clock_settime (clockid_t clock_id, const struct timespec *tp)
> {
> /* For WORDSIZE==32 systems the headers could still have defined
> __NR_clock_settime, but the kernel itself may not support it anymore */
> #ifdef __NR_clock_settime
>   return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp);
> #endif
>
>   struct __timespec64 ts64;
>
>   valid_timespec_to_timespec64 (tp, &ts64);
>   return __clock_settime64 (clock_id, &ts64);
> }
> #endif

The "#ifdef __NR_clock_settime" is always true when __TIMESIZE != 64,
so that could be simplified to the version I suggested.

> However, there is the problem that in some point in time the glibc will
> switch to 64 bit __TIMESIZE only (probably when minimal kernel version
> for glibc would be grater than 5.1) and all __clock_settime syscalls
> would be served with __clock_settime64 (as 64 bit time support is
> always in place).
>
> After this switch the "unconverted" program will setup wrong time.

I don't understand. What does it mean to switch to __TIMESIZE=64?
Would that not break all existing binaries regardless of the implementation?

I would expect that the only thing changing after the minimum
kernel version is updated is the fallback from the public time64
interfaces to the time32 system calls, but glibc cannot drop the
public time32 interfaces as long as someone might be using those,
i.e. just before the 2038 overflow. In no case would an existing
lilbrary symbol change the data type of its arguments though.

Between adding the time64 system calls (now) and removing
the time32 system calls (in y2038), there are a couple of
intermediate steps that can be years apart, or all happen
at the same time:

- drop support for building with pre-5.1 kernel headers
- stop running on pre-5.1 kernels
- change the default for newly compiled code to time64
- drop support for building with time32

      Arnd