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

[Arnd Bergmann <arnd at arndb dot de>]

On Wed, Jun 26, 2019 at 5:03 PM Lukasz Majewski <lukma@denx.de> wrote:
> > 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>
> > >
> > > 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.
>
> Isn't this the ABI break on demand ?

It's removing an unused ABI in order to ensure that nothing uses it.
The policy is to never break things that users rely on, so you should
only disable the system calls if you control all of user space and want
to ensure that whatever works now doesn't break in the future.

> > The "#ifdef __NR_clock_settime" is always true when __TIMESIZE != 64,
> > so that could be simplified to the version I suggested.
>
> For following setup: WORDSIZE=32, TIMESIZE=32 and kernel with
> __NR_clock_settime returning -ENOSYS (disabled by embedded system
> designer in the kernel), but supporting __NR_clock_settime64 (for
> example 32 bit ARM):
>
> The policy question - shall the user space binary after calling
> clock_settime:
>
> 1. Receive -ENOSYS as the __NR_clock_settime was used to fulfill the
> request
>
> or
>
> 2. Receive 0 (operation succeed) as the available __NR_clock_settime64
> has been used to perform the requested operation.
>
>
> For the proposed patch (clock_settime) - the option 2 is now performed.

I would prefer to fail as early as possible, maybe even a failure from the
ld.so when loading a binary that links against clock_settime() on a kernel that
doesn't have the system call. That's probably too hard to implement,
so abort(), or return -ENOSYS.

Definitely don't return success, that would defeat the purpose of
disabling the syscall in the kernel, and just lead to silent incorrect
data.

> > > 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?
>
> __TIMESIZE represents the size of time_t (the glibc internal time
> representation). This change would be probably performed in the future
> after the _TIME_BITS==64 is defined by default.

I'm still not following. Which of steps listed below would that correspond
to? I guess the last one, right?

> > 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