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