This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hi Alistair,

> On Thu, Jan 16, 2020 at 11:34 PM Lukasz Majewski <lukma@denx.de>
> wrote:
> >
> > 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).  
> 
> Doesn't that mean that I can fix this all by just using if _TIME_BITS
> == 64 instead of __TIMESIZE?

Unfortunately, not. The _TIME_BITS define affects _exported_ glibc
headers. It sets __USE_TIME_BITS64, which shall NOT be used in glibc
internals:
https://github.com/lmajewski/y2038_glibc/commit/319c24507974fecdffe5182d310289b2a4cb9122#diff-a5ab6c74681eaf0569ed54f6bf0d7978R391


Instead, the glibc shall be prepared for handling those syscalls
correctly in both cases - when _TIME_BITS == 64 (Y2038 safe) is defined
or not during the compilation.

> 
> >
> > 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  
> 
> Even if time_t is 64-bit you can't pass a value larger then 32-bits to
> these functions as they get converted back to a 32-bit value for the
> kernel syscall.

The problem is with consistency:

1. Internally glibc is going to replace time_t (which may be 32 bit)
with __time64_t (as it is done indirectly with introduction of struct
__timespec64, etc). In that way glibc will be itself Y2038 safe no
matter of __TIMESIZE value (32, 64 bit).

2. The functions with 64 suffix (i.e. __getitimer64, __settime64) 

e.g.:

int
__getitimer64 (__itimer_which_t which, struct __itimerval64 *curr_value)

Will use struct __itimerval64, which will always support 64 bit time
(the same situation as with struct __itimerspec64).


Afterwards, I will define redirection for it in the exported headers -
like for example here (for timerspec_get):
https://github.com/lmajewski/y2038_glibc/commit/9844cb7beb854e21bbdc595398627777b6155c27#diff-07934c1fe09f0e6357413e138856c786R320

This redirection will force usage of __gettimer64 on ARM32 bit
(__TIMESIZE==32 && __WORDSIZE==32) when -D_TIME_BITS=64 is set during
compilation.

(I'm now finishing patches to introduce struct __timeval64 to glibc)


> 
> >
> > 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).  
> 
> In this case though the syscall is always 32-bit, so I'm not sure if
> there is a huge advantage here.

The advantage is that the consistency of function conversion will be
preserved. The __gettimer64 function will be used, even though we will
use 32 bit syscalls and when kernel (maybe?) introduce 64 bit syscalls
we will be ready.

> 
> I don't see a point of converting this function to take a 64-bit value
> if time_t is 32-bit as that doesn't give you anything.

time_t may be 32 bit or 64 on the Y2038 safe systems. It depends on
adding -D_TIME_BITS=64 during compilation.

> It does seem
> worth changing the #if to check _TIME_BITS == 64 instead of __TIMESIZE
> though.

As I've stated above - the _TIME_BITS (and __USE_TIME_BITS64) are
supposed to be "visible" in the glibc exported headers.
The __USE_TIME_BITS64 flag enables redirection for the syscalls:
https://github.com/lmajewski/y2038_glibc/commit/319c24507974fecdffe5182d310289b2a4cb9122#diff-8bdb75c23cf534160b06f2dc2183e971R67

On the glibc side one shall have time functions converted to:
https://github.com/lmajewski/y2038_glibc/commit/6367f6e061c5184b39cf7fff07ffcf8b569d765e#diff-a8bb3b17dcb4b2b40deba97323563301R33


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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]