Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval

[Lukasz Majewski <lukma at denx dot de>]

Hi Alistair, Joseph

> On Thu, Jan 16, 2020 at 11:21 AM Joseph Myers
> <joseph@codesourcery.com> wrote:
> >
> > On Thu, 16 Jan 2020, Alistair Francis wrote:
> >  
> > > > To allow it this syscall wrapper shall be converted (written)
> > > > in the same way as e.g:
> > > >
> > > > ./sysdeps/unix/sysv/linux/clock_settime.c
> > > >
> > > > (the same issue is with getitimer).
> > > >
> > > > Then only redirection when __USE_TIME_BITS64 is set are needed
> > > > to use __setitimer64/__getitimer64 on Y2038 safe systems.  
> > >
> > > I'm not sure what you mean here.
> > >
> > > There is no setitimer64/getitimer64 syscall so we need to make
> > > sure we pass a 32-bit time_t here. If __TIMESIZE == 32 then we
> > > don't need any changes and can just directly make the syscall (as
> > > we do in this patch). The conversion is only required if
> > > __TIMESIZE == 64 as we need to convert to/from a 32-bit time_t.  
> >
> > This is a point about the general structure and goals of the Y2038
> > work.
> >
> > We want to end up at a point where, on systems where time_t is
> > currently 32-bit, you can build with -D_TIME_BITS=64 and get 64-bit
> > time_t instead. That means that all time-related functions,
> > including getitimer and setitimer, will, on such systems, need to
> > have two implementations in glibc, one using 64-bit times and one
> > using 32-bit times.  
> 
> I'm still confused. If we build with -D_TIME_BITS=64 does that then
> mean that __TIMESIZE == 64 ?
> 
> In which case the user exposed time_t is 64-bit and these calls will
> take a 64-bit time_t and convert it to/from a 32-bit time_t to pass to
> the kernel. The user will only ever use/see a 64-bit time_t.
> 
> >
> > The implementation structure generally being used is that the main
> > implementation has an interface using 64-bit times (even if it ends
> > up using syscalls with 32-bit times) and the one using 32-bit times
> > is a thin  
> 
> Isn't that what is happening here when __TIMESIZE == 64 ?
> 
> > wrapper around it (if time_t is already 64-bit, the second
> > implementation does not exist and some macros ensure the first
> > implementation keeps its existing name).  Once all functions have
> > been moved to that structure, we can set things up so that all
> > those 64-bit functions are exported from glibc and add _TIME_BITS
> > support in the headers.  
> 
> Ah, do you mean that glibc should expose a 64-bit time_t version if
> __TIMESIZE == 32?

Yes, exactly.

Currently 32 bit ARM (__WORDSIZE == 32 && __TIMESIZE == 32) use 32 bit
time_t. However, after compiling the source code with -D_TIME_BITS=64
the time_t will become 64 bit.

Please find example setup for tests_y2038:
https://github.com/lmajewski/y2038-tests/blob/master/Makefile#L25
(Two binaries are build from the same sources - one is Y2038 safe and
other is not).

The notable difference between the new RV32 port and existing ARM32 is
that for new ports (i.e. RV32) the __TIMESIZE = 64 is set from the
outset.
For the latter (ARM32) the __TIMESIZE = 32 is kept and IIRC we will
NOT update it to __TIMESIZE = 64 anytime soon. Instead, in exported
headers _TIME_BITS=64 will be set by default (approach similar to the
one for _FILE_OFFSET_BITS=64).

Joseph, am I right?

> So even __TIMESIZE == 32 systems can call a 64-bit
> time_t version (even if the syscall ends up being 32-bit).

+1

Please find example conversion code for timespec_get conversion:
https://patchwork.ozlabs.org/patch/1224222/

it internally uses __clock_gettime64, which uses 64 bit time no matter
on which architecture it runs (even with __TIMESIZE==32).

Please also refer to the branch, which moves 32 bit ports closer to
being Y2038 safe:

https://github.com/lmajewski/y2038_glibc/commits/glibc_timespec_get-conversion-v1

> 
> Alistair
> 
> >
> > --
> > Joseph S. Myers
> > joseph@codesourcery.com  




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: pgpmpVzr7QJy5.pgp
Description: OpenPGP digital signature