Hi Arnd, On Mon, 27 Feb 2017 21:17:41 +0100, Arnd Bergmann <[email protected]> wrote :
> On Mon, Feb 27, 2017 at 9:06 PM, Albert ARIBAUD <[email protected]> > 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 _______________________________________________ Y2038 mailing list [email protected] https://lists.linaro.org/mailman/listinfo/y2038
