parisc64: change __kernel_suseconds_t to match glibc
authorArnd Bergmann <arnd@arndb.de>
Thu, 13 Sep 2018 15:59:50 +0000 (17:59 +0200)
committerHelge Deller <deller@gmx.de>
Fri, 26 Oct 2018 06:14:35 +0000 (08:14 +0200)
commit9a298b445514b3de08252c71833f9273b7727355
tree03e6594be9dfcc83eef614226436227eb3a35c14
parente5f6d9afa3415104e402cd69288bb03f7165eeba
parisc64: change __kernel_suseconds_t to match glibc

There are only two 64-bit architecture ports that have a 32-bit
suseconds_t: sparc64 and parisc64. I've encountered a number of problems
with this, while trying to get a proper 64-bit time_t working on 32-bit
architectures. Having a 32-bit suseconds_t combined with a 64-bit time_t
means that we get extra padding in data structures that may leak kernel
stack data to user space, and it breaks all code that assumes that
timespec and timeval have the same layout.

While we can't change sparc64, it seems that glibc on parisc64 has always
set suseconds_t to 'long', and the current version would give incorrect
results for gettimeofday() and many other interfaces: timestamps passed
from user space into the kernel result in tv_usec being always zero
(the lower bits contain the intended value but are ignored) while data
passed from the kernel to user space contains either zeroes or random
data in tv_usec.

Based on that, it seems best to change the user API in the kernel in
an incompatible way to match what glibc expects.

Note that the distros I could find (gentoo and debian) all just
have 32-bit user space, which does not suffer from this problem.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Helge Deller <deller@gmx.de>
arch/parisc/include/uapi/asm/posix_types.h