mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: Arnd Bergmann <arnd@arndb.de>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: y2038@lists.linaro.org, Thomas Gleixner <tglx@linutronix.de>,
	linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] parisc64: change __kernel_suseconds_t to match glibc
Date: Mon, 17 Sep 2018 21:46:54 +0200	[thread overview]
Message-ID: <de79d285-7cbc-e547-547b-cf3e0627950d@gmx.de> (raw)
In-Reply-To: <20180913160010.905798-1-arnd@arndb.de>

Hi Arnd,

On 13.09.2018 17:59, Arnd Bergmann wrote:
> 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.

Should this wrong behavior be visible with 32-bit userspace or
with 64-bit userspace (or both)?
I didn't noticed such wrong behavior yet.

Can you suggest some test programs to verify?
LTP seems to be correct.
 
> Based on that, it seems best to change the user API in the kernel in
> an incompatible way to match what glibc expects.

Basically that sounds the right way to go, but as said before,
I didn't see such issues.

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

That's correct.
Kernel can be 32- or 64-bit, but userspace is currentl 32-bit only.

So, breaking any 64-bit userspace is OK, since we don't have it yet.
Breaking 32-bit userspace needs some thoughts...

Helge


> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/parisc/include/uapi/asm/posix_types.h | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/parisc/include/uapi/asm/posix_types.h b/arch/parisc/include/uapi/asm/posix_types.h
> index 2785632c85e7..8dce56f5dcee 100644
> --- a/arch/parisc/include/uapi/asm/posix_types.h
> +++ b/arch/parisc/include/uapi/asm/posix_types.h
> @@ -16,9 +16,6 @@ typedef unsigned short		__kernel_mode_t;
>  typedef unsigned short		__kernel_ipc_pid_t;
>  #define __kernel_ipc_pid_t __kernel_ipc_pid_t
>  
> -typedef int			__kernel_suseconds_t;
> -#define __kernel_suseconds_t __kernel_suseconds_t
> -
>  typedef long long		__kernel_off64_t;
>  typedef unsigned long long	__kernel_ino64_t;
>  
> 


  reply	other threads:[~2018-09-17 19:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-13 15:59 Arnd Bergmann
2018-09-17 19:46 ` Helge Deller [this message]
2018-09-25 10:53   ` Arnd Bergmann
2018-09-25 17:53     ` Helge Deller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=de79d285-7cbc-e547-547b-cf3e0627950d@gmx.de \
    --to=deller@gmx.de \
    --cc=arnd@arndb.de \
    --cc=jejb@parisc-linux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=y2038@lists.linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®