From: Lukasz Majewski <lukma@denx.de>
To: Stepan Golosunov <stepan@golosunov.pp.ru>
Cc: Joseph Myers <joseph@codesourcery.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, libc-alpha@sourceware.org,
Arnd Bergmann <arnd@arndb.de>, Paul Eggert <eggert@cs.ucla.edu>
Subject: Re: [PATCH v2 2/7] y2038: Introduce __ASSUME_64BIT_TIME define
Date: Sun, 5 May 2019 22:46:23 +0200 [thread overview]
Message-ID: <20190505224623.0212d919@jawa> (raw)
In-Reply-To: <20190505141053.gzff6q4j33x5vpiy@sghpc.golosunov.pp.ru>
[-- Attachment #1: Type: text/plain, Size: 2903 bytes --]
On Sun, 5 May 2019 18:10:54 +0400
Stepan Golosunov <stepan@golosunov.pp.ru> wrote:
> 02.05.2019 в 15:04:18 +0000 Joseph Myers написал:
> > On Tue, 30 Apr 2019, Lukasz Majewski wrote:
> >
> > > - The need for explicit clearing padding when calling syscalls
> > > (as to be better safe than sorry in the future - there was related
> > > discussion started by Stepan).
> >
> > This really isn't a difficult question. What it comes down to is
> > whether the Linux kernel, in the first release version with these
> > syscalls (we don't care about old -rc versions; what matters is the
> > actual 5.1 release), ignores the padding.
> >
> > If 5.1 *release* ignores the padding, that is part of the
> > kernel/userspace ABI, in accordance with the kernel principle of
> > not breaking userspace. Thus, it is something userspace can rely
> > on, now and in the future.
> >
> > If 5.1 release does not ignore the padding, syscall presence does
> > not mean the padding is ignored by the kernel and so glibc needs to
> > clear padding. Of course, it needs to clear padding in a *copy* of
> > the value provided by the user unless the glibc API in question
> > requires the timespec value in question to be in writable memory.
> >
> > So, which is (or will be) the case in 5.1 release? Padding ignored
> > or not? If more complicated (ignored for some architectures / ABIs
> > but not for others, or depending on whether compat syscalls are in
> > use), then say so - give a precise description of the exact
> > circumstances under which the padding around a 32-bit tv_nsec will
> > or will not be ignored by the kernel on input from userspace.
>
> In current linux git it looks like padding is correctly ignored in
> 32-bit kernels (because kernel itself has 32-bit tv_nsec there) but
> the code to clear it on compat syscalls in 64-bit kernels seems to be
> broken.
>
> The patch to fix this is at
>
> https://lore.kernel.org/lkml/20190429131951.471701-1-arnd@arndb.de/
>
> but it doesn't seem like it has reached Linus yet.
>
I hope that this patch will be pulled soon (before final cut) - for that
reason we can assume that the padding is ignored by the kernel and
hence do not explicitly clear it in glibc (as it was done in sent
patches)
>
> (Hmm. I think that old ipc and socketcall syscalls in 32-bit kernels
> are broken without that patch too. They would try to read
> __kernel_timespec when callers are passing old_timespec32.)
Please correct me if I'm wrong, but this problem is related to x32
machines (and not to ARM 32 bit ones with Y2038).
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 --]
prev parent reply other threads:[~2019-05-05 20:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190414220841.20243-1-lukma@denx.de>
[not found] ` <20190414220841.20243-4-lukma@denx.de>
2019-04-20 0:20 ` [PATCH 3/6] y2038: linux: Provide __clock_settime64 implementation Stepan Golosunov
2019-04-20 11:21 ` Lukasz Majewski
2019-04-22 9:07 ` Stepan Golosunov
2019-04-22 21:45 ` Arnd Bergmann
2019-04-23 15:45 ` Lukasz Majewski
[not found] ` <20190429104613.16209-1-lukma@denx.de>
[not found] ` <20190429104613.16209-3-lukma@denx.de>
[not found] ` <alpine.DEB.2.21.1904292138430.21580@digraph.polyomino.org.uk>
[not found] ` <20190430110505.2a0c7d1a@jawa>
[not found] ` <alpine.DEB.2.21.1905021431060.4027@digraph.polyomino.org.uk>
2019-05-05 14:10 ` [PATCH v2 2/7] y2038: Introduce __ASSUME_64BIT_TIME define Stepan Golosunov
2019-05-05 20:46 ` Lukasz Majewski [this message]
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=20190505224623.0212d919@jawa \
--to=lukma@denx.de \
--cc=arnd@arndb.de \
--cc=eggert@cs.ucla.edu \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stepan@golosunov.pp.ru \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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