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

[Lukasz Majewski <lukma at denx dot de>]

Hi Arnd,

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

Isn't this the ABI break on demand ?

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

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.


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

However, I do not feel competent enough to speak about glibc long term
plans.

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

Yes, correct. 

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




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

Attachment: pgpsUYM1dWQst.pgp
Description: OpenPGP digital signature