Re: [PATCH 00/25] Change time_t and clock_t to 64 bit

Arnd Bergmann
2014-05-19T17:23:00Z

On Monday 19 May 2014 14:46:59 Joseph S. Myers wrote:
> On Mon, 19 May 2014, Arnd Bergmann wrote:
>
> Now, when the motivation is not space reduction but ensuring nothing is
> there that will break in 2038 (unless it's doing dubious things like
> storing a time_t value in an int or long in the application - something a
> reasonably stupid static analysis should be able to detect), you could
> always identify the (symbol, version) pairs for a given architecture that
> use 32-bit time_t and develop a tool that checks for binaries using
> problem symbols. (Of course, that won't help with ioctls.) Or put a
> small patch in the headers to force _TIME_BITS=64 and not allow an
> override with _TIME_BITS=32. And if the kernel had a config option to
> disable all the old interfaces, that would make problem binaries break now
> rather than in 2038.

I had already thought of the kernel option, that's probably one thing
we will do here, but it won't help if glibc then emulates the interfaces
we remove ;-)

A related question would be how you plan to support future CPU architectures
that never had the 32-bit time_t in the kernel ABI. Would you also want
to provide both 32 and 64 bit time_t to user space on those?

Then again I'm not sure how relevant glibc is to the deeply embedded
distros that would want to run without the backwards compatibility.
I suspect that uClibc, musl and bionic would just offer a compile time
switch without any emulation.

> > > > I don't know why timespec on x32 uses 'long tv_nsec', it does seem
> > > > problematic.
> > >
> > > Yes, we have a glibc bug
> > > <https://sourceware.org/bugzilla/show_bug.cgi?id=16437> about the glibc
> > > definition (64-bit tv_nsec in x32 userspace to match the kernel's 64-bit
> > > "long") being nonconforming, but without the kernel treating upper bits as
> > > padding, fixing glibc requires wrappers that copy the value and clear the
> > > upper bits.
> >
> > Ok. There is also work going on to have an x32-like ABI for ARM64, and
> > that will likely have to support big-endian as well, so then it's not
> > just about clearing the padding bits, but also having them in the right
> > place.
>
> Yes, I see no problem with putting the padding bits in the right place so
> that when the kernel is passing struct timespec values *to* userspace, it
> can just fill in the native 64-bit structure and have it automatically be
> correct when interpreted as a 32-bit structure with padding (which the
> kernel will have zeroed implicitly) on tv_nsec.

Ok.

Arnd