Re: [Y2038] Fifth draft of the Y2038 design document

[Albert ARIBAUD <albert dot aribaud at 3adev dot fr>]

Hi Arnd,

On Mon, 27 Feb 2017 21:17:41 +0100, Arnd Bergmann <arnd@arndb.de>
wrote :

> On Mon, Feb 27, 2017 at 9:06 PM, Albert ARIBAUD <albert.aribaud@3adev.fr> wrote:
> > Maybe a silly question: We all assume that userland code always goes
> > through GLIBC to invoke kernel syscalls which handle struct timespecs.
> >
> > There is the possibility, at least theoretically, that userland invoke
> > these syscalls directly.
> >
> > Should we consider this possibility, or do we deem it purely
> > theoretical?
> >
> > If we consider that not all userland syscalls are made by GLIBC, then
> > even if GLIBC checked and cleaned all struct it receives from userland
> > and passes to the kernel, it seems to me that the kernel still has to
> > check the struct timespecs it receives because they might not come
> > from GLIBC and thus, they might not have been cleaned by it.
> >
> > My feeling is that we should check the struct timespecs in the kernel
> > systematically, and in GLIBC only when using them in computations (as
> > opposed to passing them to the kernel).  
> 
> The kernel syscall interface does not always adhere to POSIX, and
> when a user calls into the syscalls directly, they should follow the
> interface that is documented in the kernel man pages instead.
> 
> If we decide to have the kernel interface done the way that Zack
> suggested based on the x32 precedent (and Linus before him when the
> x32 decision was made[1]), we'd leave it up to any libc implementation
> to either use the same timespec definition as the kernel, or use the
> POSIX definition and do the zero-pad in the syscall wrapper.
> 
>      Arnd
> 
> [1] https://lkml.org/lkml/2011/8/31/244

IIUC, on the kernel side there is a will to move away from Posix (1)
here and just make tv_nsec 64-bits with no padding when time_t is
64-bit.

If that is so, then there is little point in not doing the same on
the GLIBC side; similar definitions of struct timespec for a given
time size would remove any padding questions. 

basically the only issues remaining would then be in the application
code itself. As long as tv_nsec is signed 64-bit but holds values which
fit within a signed 32-bit integer, application code reading from and
writing to tv_nsec has no reason to fail; the only problem I see is if
some weird code implicitly depends on tv_nsec's size being 'long'.

So, essentially: do we move away from Posix regarding tv_nsec, and
define it as a 64-bit signed ?

(1) or possibly try to move Posix.

Cordialement,
Albert ARIBAUD
3ADEV