From: Lukasz Majewski <lukma@denx.de>
To: Stepan Golosunov <stepan@golosunov.pp.ru>
Cc: Arnd Bergmann <arnd@arndb.de>,
Thomas Gleixner <tglx@linutronix.de>,
Joseph Myers <joseph@codesourcery.com>,
libc-alpha@sourceware.org, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org,
Deepa Dinamani <deepa.kernel@gmail.com>
Subject: Re: [PATCH 1/2] y2038: make CONFIG_64BIT_TIME unconditional
Date: Sat, 27 Apr 2019 17:06:13 +0200 [thread overview]
Message-ID: <20190427170613.38bdfbbd@jawa> (raw)
In-Reply-To: <20190427095418.344yoomf5nwznatd@sghpc.golosunov.pp.ru>
[-- Attachment #1: Type: text/plain, Size: 3037 bytes --]
Hi Stepan,
> 27.04.2019 в 00:46:53 +0200 Lukasz Majewski написал:
> > Hi Arnd,
> >
> > > As Stepan Golosunov points out, we made a small mistake in the
> > > get_timespec64() function in the kernel. It was originally added
> > > under the assumption that CONFIG_64BIT_TIME would get enabled on
> > > all 32-bit and 64-bit architectures, but when I did the
> > > conversion, I only turned it on for 32-bit ones.
> > >
> > > The effect is that the get_timespec64() function never clears the
> > > upper half of the tv_nsec field for 32-bit tasks in compat mode.
> > > Clearing this is required for POSIX compliant behavior of
> > > functions that pass a 'timespec' structure with a 64-bit tv_sec
> > > and a 32-bit tv_nsec, plus uninitialized padding.
>
> > At least for my setup (32bit ARM with 64 bit time support) this
> > patch is not fixing anything.
>
> The patch is not supposed to fix anything on 32-bit architectures as
> in-kernel struct timespec64 has 32-bit tv_nsec there. Thus truncation
> should happen automatically. I also missed that fact when I was
> reading get_timespec64 code.
Yes. You are right. The tv_nsec is 32 bit.
>
> (I am wondering whether such trucation is undefined behaviour in C
According to [1] - Chapter 6.3.1.3 - Point 3 it is
implementation-defined.
> and
> whether there should be sign-extension instead of zeroing-out for the
> in_compat_syscall() case though.)
What I've found is that "typically" the high order bits are discarded.
However, it is still "implementation dependent".
>
> > > The easiest fix for linux-5.1 is to just make the Kconfig symbol
> > > unconditional, as it was originally intended. As a follow-up,
> > > we should remove any #ifdef CONFIG_64BIT_TIME completely.
> > >
> > > Link:
> > > https://lore.kernel.org/lkml/20190422090710.bmxdhhankurhafxq@sghpc.golosunov.pp.ru/
> > > Cc: Lukasz Majewski <lukma@denx.de> Cc: Stepan Golosunov
> > > <stepan@golosunov.pp.ru> Signed-off-by: Arnd Bergmann
> > > <arnd@arndb.de> ---
> > > Please apply this one as a bugfix for 5.1
> > > ---
> > > arch/Kconfig | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/Kconfig b/arch/Kconfig
> > > index 33687dddd86a..9092e0ffe4d3 100644
> > > --- a/arch/Kconfig
> > > +++ b/arch/Kconfig
> > > @@ -764,7 +764,7 @@ config COMPAT_OLD_SIGACTION
> > > bool
> > >
> > > config 64BIT_TIME
> > > - def_bool ARCH_HAS_64BIT_TIME
> > > + def_bool y
> > > help
> > > This should be selected by all architectures that need
> > > to support new system calls with a 64-bit time_t. This is
> > > relevant on all 32-bit
Note:
[1] - http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-04-27 15:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-26 14:25 [PATCH 1/2] y2038: make CONFIG_64BIT_TIME unconditional Arnd Bergmann
2019-04-26 14:25 ` [PATCH 2/2] y2038: remove CONFIG_64BIT_TIME Arnd Bergmann
2019-04-26 14:25 ` Arnd Bergmann
2019-04-26 22:46 ` [PATCH 1/2] y2038: make CONFIG_64BIT_TIME unconditional Lukasz Majewski
2019-04-27 9:54 ` Stepan Golosunov
2019-04-27 15:06 ` Lukasz Majewski [this message]
2019-04-27 20:47 ` Arnd Bergmann
2019-04-29 7:33 ` Thomas Gleixner
2019-04-29 13:22 ` Arnd Bergmann
-- strict thread matches above, loose matches on Subject: below --
2019-04-29 13:19 Arnd Bergmann
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=20190427170613.38bdfbbd@jawa \
--to=lukma@denx.de \
--cc=arnd@arndb.de \
--cc=deepa.kernel@gmail.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stepan@golosunov.pp.ru \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.