This is a mostly unchanged copy of a series I sent back in April for
an initial review. All the earlier syscall patches that Deepa or I sent
got merged now, and this is the largest chunk of remaining patches.
Changes this time are:
- This is actually tested with the LTP syscalls test suite,
both before and after the CONFIG_64BIT_TIME change (which is not
included here). I have created a patch series for musl libc to use
64-bit time_t and change all the system calls over to the new entry
points for this. The only bugs I found during that testing were in
later parts of the conversion that I have not posted yet.
- I rewrote the sys_io_getevents conversion after the
introduction of sys_sys_io_getevents. We obviously don't need to have
two of each, so we will only provide sys_io_pgetevents() with 64-bit
time_t but not sys_io_getevents(), which the libc can implement on
top of the former.
- While we have Deepa's POSIX timer conversion merged now, we
still need to decide on how we want to do the replacement
ABI for getitimer()/setitimer(). Like getrusage()/waitid() and
clock_adjtime() and unlike the system calls I'm posting here,
there is no one obvious ABI.
- For ppoll()/pselect6(), the ABI is fairly clear, but the
implementation still needs to be done. I tested with a simple
prototype based on the existing compat code, but we can
probably improve that. This is something that Deepa still
wants to work on.
- Finally, Christoph Hellwig objected to the idea of reusing the
compat_ namespace for the 32-bit native case. Changing that
would be a departure from our plans so far[2], and would make
some things end up differently. Until we have decided on how this
is to be done, I've decided to not change the code for this
post. We can clearly rename all the symbols and I've implemented
that in [3] for the current linux-next (not including the
series here). This is something we can definitely do, but I'd
need to know soon whether we can merge this series unchanged
for 4.19 or if I should rebase it on top of that patch with the
alternative naming.
Arnd
---
Previous cover letter announcement below, see [4] for the full
series:
After the first timekeeping series from Deepa (merged into -tip now)
and my follow-up for IPC system calls, this is a third set of system
call conversions following the same principle.
Most of the changes are straightforward, so I'm grouping them into a
larger series even though the system calls are mostly unrelated to one
another. After this series, the remaining calls that need to be changed
are getrusage()/waitid(), pselect6/ppoll(), timer{,fd}_{get,set}time()
and getitimer()/setitimer(). Those will be sent separately, once they
are matured enough.
To put the changes into perspective, a list of all system calls that
require changes is available in a spreadsheet[5] and I have made
another experimental patch that changes over x86[6] and arm[7] to
actually use them.
Link [1] https://lore.kernel.org/lkml/20180712082034.GA8802@infradead.org/
Link [2] https://lwn.net/Articles/643234/
Link [3] https://lore.kernel.org/lkml/20180713133204.3123939-1-arnd@arndb.de/
Link [4] https://lore.kernel.org/lkml/20180425160311.2718314-1-arnd@arndb.de/
Link [5] https://docs.google.com/spreadsheets/d/1HCYwHXxs48TsTb6IGUduNjQnmfRvMPzCN6T_0YiQwis
Link [6] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/commit/?h=y2038-4.18-rc5-next&id=2c995de3bdd5
Link [7] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/commit/?h=y2038-4.18-rc5-next&id=e73061da2f80
Arnd Bergmann (17):
y2038: compat: Move common compat types to asm-generic/compat.h
y2038: Remove newstat family from default syscall set
y2038: Remove stat64 family from default syscall set
asm-generic: Remove unneeded __ARCH_WANT_SYS_LLSEEK macro
asm-generic: Remove empty asm/unistd.h
y2038: Change sys_utimensat() to use __kernel_timespec
y2038: Compile utimes()/futimesat() conditionally
y2038: utimes: Rework #ifdef guards for compat syscalls
y2038: futex: Move compat implementation into futex.c
y2038: futex: Add support for __kernel_timespec
y2038: Prepare sched_rr_get_interval for __kernel_timespec
y2038: aio: Prepare sys_io_{p,}getevents for __kernel_timespec
y2038: socket: Convert recvmmsg to __kernel_timespec
y2038: socket: Add compat_sys_recvmmsg_time64
y2038: signal: Change rt_sigtimedwait to use __kernel_timespec
y2038: Make compat_sys_rt_sigtimedwait usable on 32-bit
y2038: signal: Add compat_sys_rt_sigtimedwait_time64
arch/alpha/include/asm/unistd.h | 2 +
arch/arc/include/uapi/asm/unistd.h | 1 +
arch/arm/include/asm/unistd.h | 4 +-
arch/arm64/include/asm/compat.h | 20 +--
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/uapi/asm/unistd.h | 1 +
arch/c6x/include/uapi/asm/unistd.h | 1 +
arch/h8300/include/uapi/asm/unistd.h | 1 +
arch/hexagon/include/uapi/asm/unistd.h | 1 +
arch/ia64/include/asm/unistd.h | 3 +
arch/m68k/include/asm/unistd.h | 2 +-
arch/microblaze/include/asm/unistd.h | 2 +-
arch/mips/include/asm/compat.h | 22 +---
arch/mips/include/asm/unistd.h | 3 +-
arch/nds32/include/uapi/asm/unistd.h | 1 +
arch/nios2/include/uapi/asm/unistd.h | 1 +
arch/openrisc/include/uapi/asm/unistd.h | 1 +
arch/parisc/include/asm/compat.h | 18 +--
arch/parisc/include/asm/unistd.h | 3 +-
arch/powerpc/include/asm/compat.h | 18 +--
arch/powerpc/include/asm/unistd.h | 3 +-
arch/s390/include/asm/compat.h | 18 +--
arch/s390/include/asm/unistd.h | 3 +-
arch/sh/include/asm/unistd.h | 2 +-
arch/sparc/include/asm/compat.h | 19 +--
arch/sparc/include/asm/unistd.h | 3 +-
arch/unicore32/include/uapi/asm/unistd.h | 1 +
arch/x86/include/asm/compat.h | 19 +--
arch/x86/include/asm/unistd.h | 3 +-
arch/xtensa/include/asm/unistd.h | 2 +-
fs/aio.c | 77 ++++++++++--
fs/read_write.c | 2 +-
fs/stat.c | 3 +
fs/utimes.c | 59 +++++----
include/asm-generic/compat.h | 24 +++-
include/asm-generic/unistd.h | 13 --
include/linux/compat.h | 12 +-
include/linux/compat_time.h | 5 +
include/linux/futex.h | 8 --
include/linux/socket.h | 19 ++-
include/linux/syscalls.h | 25 ++--
include/uapi/asm-generic/unistd.h | 2 +
kernel/Makefile | 3 -
kernel/futex.c | 207 +++++++++++++++++++++++++++++--
kernel/futex_compat.c | 202 ------------------------------
kernel/sched/core.c | 4 +-
kernel/signal.c | 68 ++++++++--
kernel/sys_ni.c | 1 +
net/compat.c | 16 +--
net/socket.c | 55 ++++++--
50 files changed, 524 insertions(+), 461 deletions(-)
delete mode 100644 include/asm-generic/unistd.h
delete mode 100644 kernel/futex_compat.c
--
2.9.0
When 32-bit architectures get changed to support 64-bit time_t,
utimensat() needs to use the new __kernel_timespec structure as its
argument.
The older utime(), utimes() and futimesat() system calls don't need a
corresponding change as they are no longer used on C libraries that have
64-bit time support.
As we do for the other syscalls that have timespec arguments, we reuse
the 'compat' syscall entry points to implement the traditional four
interfaces, and only leave the new utimensat() as a native handler,
so that the same code gets used on both 32-bit and 64-bit kernels
on each syscall.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
fs/utimes.c | 2 +-
include/linux/syscalls.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
From: Christoph Hellwig <hch@infradead.org> Date: 2018-07-17 13:25:19
On Mon, Jul 16, 2018 at 06:10:52PM +0200, Arnd Bergmann wrote:
When 32-bit architectures get changed to support 64-bit time_t,
utimensat() needs to use the new __kernel_timespec structure as its
argument.
The older utime(), utimes() and futimesat() system calls don't need a
corresponding change as they are no longer used on C libraries that have
64-bit time support.
As we do for the other syscalls that have timespec arguments, we reuse
the 'compat' syscall entry points to implement the traditional four
interfaces, and only leave the new utimensat() as a native handler,
so that the same code gets used on both 32-bit and 64-bit kernels
on each syscall.
I wonder about the direction here: wouldn't it be easier to just
leave th existing syscall names as-is and introduce a new utimesat64
which uses the new timespec? We can then drop the old legacy utimesat
for new architectures added after the cutover.
On Tue, Jul 17, 2018 at 2:52 PM, Christoph Hellwig [off-list ref] wrote:
On Mon, Jul 16, 2018 at 06:10:52PM +0200, Arnd Bergmann wrote:
quoted
When 32-bit architectures get changed to support 64-bit time_t,
utimensat() needs to use the new __kernel_timespec structure as its
argument.
The older utime(), utimes() and futimesat() system calls don't need a
corresponding change as they are no longer used on C libraries that have
64-bit time support.
As we do for the other syscalls that have timespec arguments, we reuse
the 'compat' syscall entry points to implement the traditional four
interfaces, and only leave the new utimensat() as a native handler,
so that the same code gets used on both 32-bit and 64-bit kernels
on each syscall.
I wonder about the direction here: wouldn't it be easier to just
leave th existing syscall names as-is and introduce a new utimesat64
which uses the new timespec? We can then drop the old legacy utimesat
for new architectures added after the cutover.
We have debated both approaches over several years, but for
most syscalls, we picked the approach described above, for multiple
reasons:
- For any system call that takes a time_t derived argument, we
already have two implementations (native and compat), so adding a
third one requires duplicating some code.
- I want to avoid adding an implementation that is not well tested
if possible, to make it less likely to introduce security holes or
subtle bugs that we can't fix later without breaking the ABI.
Using the same implementation for the new 32-bit case that
we have for the existing 64-bit case means that this code is
much better exercised, while reusing the compat code for the
traditional native syscall means it gets exercised by all current
user space, which makes it more likely to catch bugs early.
- Looking at the end result, I find it more logical to have each
of the converted syscalls implement the same binary interface
on both 32-bit and 64-bit architectures with the same code,
and have the old 32-bit implementation be similarly shared.
This is even more important once we add new architectures
that don't even provide the 32-bit time_t interfaces and just
leave out the old entry points.
Arnd
This is a preparation patch for converting sys_sched_rr_get_interval to
work with 64-bit time_t on 32-bit architectures. The 'interval' argument
is changed to struct __kernel_timespec, which will be redefined using
64-bit time_t in the future. The compat version of the system call in
turn is enabled for compilation with CONFIG_COMPAT_32BIT_TIME so
the individual 32-bit architectures can share the handling of the
traditional argument with 64-bit architectures providing it for their
compat mode.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/syscalls.h | 2 +-
kernel/sched/core.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
Nothing is left in asm/unistd.h except for the redirect to
uapi/asm/unistd.h, so removing the file simply leads to that one being
used directly. The linux/export.h inclusion is a leftover from commit
e1b5bb6d1236 ("consolidate cond_syscall and SYSCALL_ALIAS declarations")
and should not be used anyway.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/asm-generic/unistd.h | 3 ---
1 file changed, 3 deletions(-)
delete mode 100644 include/asm-generic/unistd.h
From: Christoph Hellwig <hch@infradead.org> Date: 2018-07-17 13:23:57
On Mon, Jul 16, 2018 at 06:10:51PM +0200, Arnd Bergmann wrote:
Nothing is left in asm/unistd.h except for the redirect to
uapi/asm/unistd.h, so removing the file simply leads to that one being
used directly. The linux/export.h inclusion is a leftover from commit
e1b5bb6d1236 ("consolidate cond_syscall and SYSCALL_ALIAS declarations")
and should not be used anyway.
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
Now that 32-bit architectures have two variants of
sys_rt_sigtimedwaid() for 32-bit and 64-bit time_t, we also
need to have a second compat system call entry point on the
corresponding 64-bit architectures.
The traditional system call keeps getting handled
by compat_sys_rt_sigtimedwait(), and this adds a new
compat_sys_rt_sigtimedwait_time64() that differs only in
the timeout argument type.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
kernel/signal.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
New architectures should no longer need stat64, which is not y2038
safe and has been replaced by statx(). This removes the 'select
__ARCH_WANT_STAT64' statement from asm-generic/unistd.h and instead
moves it into the respective asm/unistd.h UAPI header files for each
architecture that uses it today.
In the generic file, the system call number and entry points are now
made conditional, so newly added architectures (e.g. riscv32 or csky)
will never need to carry backwards compatiblity for it.
arm64 is the only 64-bit architecture using the asm-generic/unistd.h
file, and it already sets __ARCH_WANT_NEW_STAT in its headers, and I
use the same #ifdef here: future 64-bit architectures therefore won't
see newstat or stat64 any more. They don't suffer from the y2038 time_t
overflow, but for consistency it seems best to also let them use statx().
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arc/include/uapi/asm/unistd.h | 1 +
arch/c6x/include/uapi/asm/unistd.h | 1 +
arch/h8300/include/uapi/asm/unistd.h | 1 +
arch/hexagon/include/uapi/asm/unistd.h | 1 +
arch/nds32/include/uapi/asm/unistd.h | 1 +
arch/nios2/include/uapi/asm/unistd.h | 1 +
arch/openrisc/include/uapi/asm/unistd.h | 1 +
arch/unicore32/include/uapi/asm/unistd.h | 1 +
include/asm-generic/unistd.h | 1 -
include/uapi/asm-generic/unistd.h | 2 ++
10 files changed, 10 insertions(+), 1 deletion(-)
@@ -1,6 +1,7 @@// SPDX-License-Identifier: GPL-2.0// Copyright (C) 2005-2017 Andes Technology Corporation+#define __ARCH_WANT_STAT64#define __ARCH_WANT_SYNC_FILE_RANGE2/* Use the standard ABI for syscalls */
@@ -19,6 +19,7 @@#define sys_mmap2 sys_mmap_pgoff#define __ARCH_WANT_RENAMEAT+#define __ARCH_WANT_STAT64/* Use the standard ABI for syscalls */#include<asm-generic/unistd.h>
There are four generations of utimes() syscalls: utime(), utimes(),
futimesat() and utimensat(), each one being a superset of the previous
one. For y2038 support, we have to add another one, which is the same
as the existing utimensat() but always passes 64-bit times_t based
timespec values.
There are currently 10 architectures that only use utimensat(), two
that use utimes(), futimesat() and utimensat() but not utime(), and 11
architectures that have all four, and those define __ARCH_WANT_SYS_UTIME
in order to get a sys_utime implementation. Since all the new
architectures only want utimensat(), moving all the legacy entry points
into a common __ARCH_WANT_SYS_UTIME guard simplifies the logic. Only alpha
and ia64 grow a tiny bit as they now also get an unused sys_utime(),
but it didn't seem worth the extra complexity of adding yet another
ifdef for those.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/alpha/include/asm/unistd.h | 1 +
arch/arm/include/asm/unistd.h | 2 +-
arch/ia64/include/asm/unistd.h | 1 +
fs/utimes.c | 51 ++++++++++++++++++-----------------------
include/linux/syscalls.h | 10 ++++----
5 files changed, 31 insertions(+), 34 deletions(-)
@@ -8,35 +8,6 @@#include<linux/compat.h>#include<asm/unistd.h>-#ifdef __ARCH_WANT_SYS_UTIME--/*-*sys_utime()canbeimplementedinuser-levelusingsys_utimes().-*Isthisforbackwardscompatibility?Ifso,whynotmoveit-*intotheappropriatearchdirectory(forthosearchitecturesthat-*needit).-*/--/* If times==NULL, set access and modification to current time,-*mustbeownerorhavewritepermission.-*Else,updatefrom*times,mustbeownerorsuperuser.-*/-SYSCALL_DEFINE2(utime,char__user*,filename,structutimbuf__user*,times)-{-structtimespec64tv[2];--if(times){-if(get_user(tv[0].tv_sec,×->actime)||-get_user(tv[1].tv_sec,×->modtime))-return-EFAULT;-tv[0].tv_nsec=0;-tv[1].tv_nsec=0;-}-returndo_utimes(AT_FDCWD,filename,times?tv:NULL,0);-}--#endif-staticboolnsec_valid(longnsec){if(nsec==UTIME_OMIT||nsec==UTIME_NOW)
@@ -965,8 +965,6 @@ asmlinkage long sys_access(const char __user *filename, int mode);asmlinkagelongsys_rename(constchar__user*oldname,constchar__user*newname);asmlinkagelongsys_symlink(constchar__user*old,constchar__user*new);-asmlinkagelongsys_utimes(char__user*filename,-structtimeval__user*utimes);#if defined(__ARCH_WANT_STAT64) || defined(__ARCH_WANT_COMPAT_STAT64)asmlinkagelongsys_stat64(constchar__user*filename,structstat64__user*statbuf);
@@ -996,14 +994,18 @@ asmlinkage long sys_alarm(unsigned int seconds);asmlinkagelongsys_getpgrp(void);asmlinkagelongsys_pause(void);asmlinkagelongsys_time(time_t__user*tloc);+#ifdef __ARCH_WANT_SYS_UTIMEasmlinkagelongsys_utime(char__user*filename,structutimbuf__user*times);+asmlinkagelongsys_utimes(char__user*filename,+structtimeval__user*utimes);+asmlinkagelongsys_futimesat(intdfd,constchar__user*filename,+structtimeval__user*utimes);+#endifasmlinkagelongsys_creat(constchar__user*pathname,umode_tmode);asmlinkagelongsys_getdents(unsignedintfd,structlinux_dirent__user*dirent,unsignedintcount);-asmlinkagelongsys_futimesat(intdfd,constchar__user*filename,-structtimeval__user*utimes);asmlinkagelongsys_select(intn,fd_set__user*inp,fd_set__user*outp,fd_set__user*exp,structtimeval__user*tvp);asmlinkagelongsys_poll(structpollfd__user*ufds,unsignedintnfds,
Once sys_rt_sigtimedwait() gets changed to a 64-bit time_t, we have
to provide compatibility support for existing binaries. Using the
compat_sys_rt_sigtimedwait() entry point is convenient because it allows
to share the implementation with 64-bit architectures.
Unfortunately, the get_compat_sigset() and copy_siginfo_to_user32()
functions are used in that function, but we can replace them with
trivial helpers that do the same thing as before.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
kernel/signal.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
The sys_llseek sytem call is needed on all 32-bit architectures and
none of the 64-bit ones, so we can remove the __ARCH_WANT_SYS_LLSEEK guard
and simplify the include/asm-generic/unistd.h header further.
Since 32-bit tasks can run either natively or in compat mode on 64-bit
architectures, we have to check for both !CONFIG_64BIT and CONFIG_COMPAT.
There are a few 64-bit architectures that also reference sys_llseek
in their 64-bit ABI (e.g. sparc), but I verified that those all
select CONFIG_COMPAT, so the #if check is still correct here. It's
a bit odd to include it in the syscall table though, as it's the
same as sys_lseek() on 64-bit, but with strange calling conventions.
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/include/asm/unistd.h | 1 -
arch/arm64/include/asm/unistd.h | 1 -
arch/m68k/include/asm/unistd.h | 1 -
arch/microblaze/include/asm/unistd.h | 1 -
arch/mips/include/asm/unistd.h | 1 -
arch/parisc/include/asm/unistd.h | 1 -
arch/powerpc/include/asm/unistd.h | 1 -
arch/s390/include/asm/unistd.h | 1 -
arch/sh/include/asm/unistd.h | 1 -
arch/sparc/include/asm/unistd.h | 1 -
arch/x86/include/asm/unistd.h | 1 -
arch/xtensa/include/asm/unistd.h | 1 -
fs/read_write.c | 2 +-
include/asm-generic/unistd.h | 9 ---------
14 files changed, 1 insertion(+), 22 deletions(-)
From: Christoph Hellwig <hch@infradead.org> Date: 2018-07-17 13:23:53
On Mon, Jul 16, 2018 at 06:10:50PM +0200, Arnd Bergmann wrote:
The sys_llseek sytem call is needed on all 32-bit architectures and
none of the 64-bit ones, so we can remove the __ARCH_WANT_SYS_LLSEEK guard
and simplify the include/asm-generic/unistd.h header further.
Since 32-bit tasks can run either natively or in compat mode on 64-bit
architectures, we have to check for both !CONFIG_64BIT and CONFIG_COMPAT.
There are a few 64-bit architectures that also reference sys_llseek
in their 64-bit ABI (e.g. sparc), but I verified that those all
select CONFIG_COMPAT, so the #if check is still correct here. It's
a bit odd to include it in the syscall table though, as it's the
same as sys_lseek() on 64-bit, but with strange calling conventions.
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
This is a preparation patch for converting sys_io_pgetevents to
work with 64-bit time_t on 32-bit architectures. The 'timeout' argument
is changed to struct __kernel_timespec, which will be redefined using
64-bit time_t in the future. The compat version of the system call in
turn is enabled for compilation with CONFIG_COMPAT_32BIT_TIME so
the individual 32-bit architectures can share the handling of the
traditional argument with 64-bit architectures providing it for their
compat mode.
We now have five entry points into do_io_getevents(). Until we set
CONFIG_64BIT_TIME, the arguments are
sys_io_getevents(): native aio_context_t, old-style timespec
sys_io_pgetevents(): like sys_io_getevents(), but with added
aio_sigset argument
compat_sys_io_getevents(): 32-bit aio_context_t, 32-bit timespec
compat_sys_io_pgetevents(): like compat_sys_io_getevents(), but with
added aio_sigset argument
compat_sys_io_pgetevents_time64(): like compat_sys_io_pgetevents(),
but with 64-bit timespec
Once a 32-bit architecture sets CONFIG_64BIT_TIME, sys_io_getevents()
is no longer available, and sys_io_pgetevents() takes a 64-bit timespec
argument, whiel compat_sys_io_getevents() and compat_sys_io_pgetevents()
implement the traditional behavior. compat_sys_io_pgetevents_time64()
is only used on 64-bit architectures, to provide compatibility with
the new 32-bit version of sys_io_pgetevents() taking a 64-bit timespec
combined with a __compat_aio_sigset.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
fs/aio.c | 77 +++++++++++++++++++++++++++++++++++++++++++-----
include/linux/syscalls.h | 4 +--
2 files changed, 71 insertions(+), 10 deletions(-)
While converting compat system call handlers to work on 32-bit
architectures, I found a number of types used in those handlers
that are identical between all architectures.
Let's move all the identical ones into asm-generic/compat.h to avoid
having to add even more identical definitions of those types.
For unknown reasons, mips defines __compat_gid32_t, __compat_uid32_t
and compat_caddr_t as signed, while all others have them unsigned.
This seems to be a mistake, but I'm leaving it alone here. The other
types all differ by size or alignment on at least on architecture.
compat_aio_context_t is currently defined in linux/compat.h but
also needed for compat_sys_io_getevents(), so let's move it into
the same place.
While we still have not decided whether the 32-bit time handling
will always use the compat syscalls, or in which form, I think this
is a useful cleanup that we can merge regardless.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm64/include/asm/compat.h | 20 ++------------------
arch/mips/include/asm/compat.h | 22 ++--------------------
arch/parisc/include/asm/compat.h | 18 ++----------------
arch/powerpc/include/asm/compat.h | 18 ++----------------
arch/s390/include/asm/compat.h | 18 ++----------------
arch/sparc/include/asm/compat.h | 19 ++-----------------
arch/x86/include/asm/compat.h | 19 ++-----------------
include/asm-generic/compat.h | 24 +++++++++++++++++++++++-
include/linux/compat.h | 2 --
9 files changed, 37 insertions(+), 123 deletions(-)
@@ -1,3 +1,25 @@/* SPDX-License-Identifier: GPL-2.0 */+#ifndef __ASM_GENERIC_COMPAT_H+#define __ASM_GENERIC_COMPAT_H-/* This is an empty stub for 32-bit-only architectures */+/* These types are common across all compat ABIs */+typedefu32compat_size_t;+typedefs32compat_ssize_t;+typedefs32compat_clock_t;+typedefs32compat_pid_t;+typedefu32compat_ino_t;+typedefs32compat_off_t;+typedefs64compat_loff_t;+typedefs32compat_daddr_t;+typedefs32compat_timer_t;+typedefs32compat_key_t;+typedefs16compat_short_t;+typedefs32compat_int_t;+typedefs32compat_long_t;+typedefu16compat_ushort_t;+typedefu32compat_uint_t;+typedefu32compat_ulong_t;+typedefu32compat_uptr_t;+typedefu32compat_aio_context_t;++#endif
From: Christoph Hellwig <hch@infradead.org> Date: 2018-07-17 13:22:02
On Mon, Jul 16, 2018 at 06:10:47PM +0200, Arnd Bergmann wrote:
While converting compat system call handlers to work on 32-bit
architectures, I found a number of types used in those handlers
that are identical between all architectures.
Let's move all the identical ones into asm-generic/compat.h to avoid
having to add even more identical definitions of those types.
For unknown reasons, mips defines __compat_gid32_t, __compat_uid32_t
and compat_caddr_t as signed, while all others have them unsigned.
This seems to be a mistake, but I'm leaving it alone here. The other
types all differ by size or alignment on at least on architecture.
compat_aio_context_t is currently defined in linux/compat.h but
also needed for compat_sys_io_getevents(), so let's move it into
the same place.
While we still have not decided whether the 32-bit time handling
will always use the compat syscalls, or in which form, I think this
is a useful cleanup that we can merge regardless.
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
After changing over to 64-bit time_t syscalls, many architectures will
want compat_sys_utimensat() but not respective handlers for utime(),
utimes() and futimesat(). This adds a new __ARCH_WANT_COMPAT_SYS_UTIME
to complement __ARCH_WANT_SYS_UTIME. For now, all 64-bit architectures
that support CONFIG_COMPAT set it, but future 64-bit architectures will
not (tile would not have needed it either, but got removed).
As older 32-bit architectures get converted to using CONFIG_64BIT_TIME,
they will have to use __ARCH_WANT_COMPAT_SYS_UTIME instead of
__ARCH_WANT_SYS_UTIME. Architectures using the generic syscall ABI
don't need either of them as they never had a utime syscall.
Since the compat_utimbuf structure is now required outside of
CONFIG_COMPAT, I'm moving it into compat_time.h.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
If we proceed with Christoph's suggestion of renaming all the compat
time handling to something that doesn't have compat in the name,
the new macro here would have to get renamed as well.
---
arch/arm64/include/asm/unistd.h | 1 +
arch/mips/include/asm/unistd.h | 1 +
arch/parisc/include/asm/unistd.h | 1 +
arch/powerpc/include/asm/unistd.h | 1 +
arch/s390/include/asm/unistd.h | 1 +
arch/sparc/include/asm/unistd.h | 1 +
arch/x86/include/asm/unistd.h | 1 +
fs/utimes.c | 6 +++++-
include/linux/compat.h | 5 -----
include/linux/compat_time.h | 5 +++++
10 files changed, 17 insertions(+), 6 deletions(-)
This prepares sys_futex for y2038 safe calling: the native
syscall is changed to receive a __kernel_timespec argument, which
will be switched to 64-bit time_t in the future. All the internal
time handling gets changed to timespec64, and the compat_sys_futex
entry point is moved under the CONFIG_COMPAT_32BIT_TIME check
to provide compatibility for existing 32-bit architectures.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/syscalls.h | 2 +-
kernel/futex.c | 22 ++++++++++++----------
2 files changed, 13 insertions(+), 11 deletions(-)
This changes sys_rt_sigtimedwait() to use get_timespec64(), changing
the timeout type to __kernel_timespec, which will be changed to use
a 64-bit time_t in the future. Since the do_sigtimedwait() core
function changes, we also have to modify the compat version of this
system call in the same way.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/syscalls.h | 2 +-
kernel/signal.c | 17 +++++++++--------
2 files changed, 10 insertions(+), 9 deletions(-)
This converts the recvmmsg() system call in all its variations to use
'timespec64' internally for its timeout, and have a __kernel_timespec64
argument in the native entry point. This lets us change the type to use
64-bit time_t at a later point while using the 32-bit compat system call
emulation for existing user space.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/socket.h | 4 ++--
include/linux/syscalls.h | 2 +-
net/compat.c | 6 +++---
net/socket.c | 18 ++++++++----------
4 files changed, 14 insertions(+), 16 deletions(-)
We are going to share the compat_sys_futex() handler between 64-bit
architectures and 32-bit architectures that need to deal with both 32-bit
and 64-bit time_t, and this is easier if both entry points are in the
same file.
In fact, most other system call handlers do the same thing these days, so
let's follow the trend here and merge all of futex_compat.c into futex.c.
In the process, a few minor changes have to be done to make sure everything
still makes sense: handle_futex_death() and futex_cmpxchg_enabled() become
local symbol, and the compat version of the fetch_robust_entry() function
gets renamed to compat_fetch_robust_entry() to avoid a symbol clash.
This is intended as a purely cosmetic patch, no behavior should
change.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Regardless of whether we rename all compat time calls or not, moving the
compat futex code into the main file helps us clean up the implementation.
---
include/linux/futex.h | 8 --
kernel/Makefile | 3 -
kernel/futex.c | 195 +++++++++++++++++++++++++++++++++++++++++++++++-
kernel/futex_compat.c | 202 --------------------------------------------------
4 files changed, 192 insertions(+), 216 deletions(-)
delete mode 100644 kernel/futex_compat.c
We have four generations of stat() syscalls:
- the oldstat syscalls that are only used on the older architectures
- the newstat family that is used on all 64-bit architectures but
lacked support for large files on 32-bit architectures.
- the stat64 family that is used mostly on 32-bit architectures to
replace newstat
- statx() to replace all of the above, adding 64-bit timestamps among
other things.
We already compile stat64 only on those architectures that need it,
but newstat is always built, including on those that don't reference
it. This adds a new __ARCH_WANT_NEW_STAT symbol along the lines of
__ARCH_WANT_OLD_STAT and __ARCH_WANT_STAT64 to control compilation of
newstat. All architectures that need it use an explict define, the
others now get a little bit smaller, and future architecture (including
64-bit targets) won't ever see it.
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/alpha/include/asm/unistd.h | 1 +
arch/arm/include/asm/unistd.h | 1 +
arch/arm64/include/uapi/asm/unistd.h | 1 +
arch/ia64/include/asm/unistd.h | 2 ++
arch/m68k/include/asm/unistd.h | 1 +
arch/microblaze/include/asm/unistd.h | 1 +
arch/mips/include/asm/unistd.h | 1 +
arch/parisc/include/asm/unistd.h | 1 +
arch/powerpc/include/asm/unistd.h | 1 +
arch/s390/include/asm/unistd.h | 1 +
arch/sh/include/asm/unistd.h | 1 +
arch/sparc/include/asm/unistd.h | 1 +
arch/x86/include/asm/unistd.h | 1 +
arch/xtensa/include/asm/unistd.h | 1 +
fs/stat.c | 3 +++
15 files changed, 18 insertions(+)
From: Christoph Hellwig <hch@infradead.org> Date: 2018-07-17 13:23:14
On Mon, Jul 16, 2018 at 06:10:48PM +0200, Arnd Bergmann wrote:
We have four generations of stat() syscalls:
- the oldstat syscalls that are only used on the older architectures
- the newstat family that is used on all 64-bit architectures but
lacked support for large files on 32-bit architectures.
- the stat64 family that is used mostly on 32-bit architectures to
replace newstat
- statx() to replace all of the above, adding 64-bit timestamps among
other things.
We already compile stat64 only on those architectures that need it,
but newstat is always built, including on those that don't reference
it. This adds a new __ARCH_WANT_NEW_STAT symbol along the lines of
__ARCH_WANT_OLD_STAT and __ARCH_WANT_STAT64 to control compilation of
newstat. All architectures that need it use an explict define, the
others now get a little bit smaller, and future architecture (including
64-bit targets) won't ever see it.
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Do I read this right that you only want to provide statx by default?
It is a little different from the traditional stat calls, so I'd like
to know this is actually ok from libc folks first.
On Tue, Jul 17, 2018 at 2:50 PM, Christoph Hellwig [off-list ref] wrote:
On Mon, Jul 16, 2018 at 06:10:48PM +0200, Arnd Bergmann wrote:
quoted
We have four generations of stat() syscalls:
- the oldstat syscalls that are only used on the older architectures
- the newstat family that is used on all 64-bit architectures but
lacked support for large files on 32-bit architectures.
- the stat64 family that is used mostly on 32-bit architectures to
replace newstat
- statx() to replace all of the above, adding 64-bit timestamps among
other things.
We already compile stat64 only on those architectures that need it,
but newstat is always built, including on those that don't reference
it. This adds a new __ARCH_WANT_NEW_STAT symbol along the lines of
__ARCH_WANT_OLD_STAT and __ARCH_WANT_STAT64 to control compilation of
newstat. All architectures that need it use an explict define, the
others now get a little bit smaller, and future architecture (including
64-bit targets) won't ever see it.
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Do I read this right that you only want to provide statx by default?
Yes, that is correct.
It is a little different from the traditional stat calls, so I'd like
to know this is actually ok from libc folks first.
That would definitely help. See below for the stat implementation
I did in my musl libc prototype based on statx(). It passes the
LTP syscall tests, but that doesn't mean all the corner cases
are correct.
Arnd
From: Joseph Myers <hidden> Date: 2018-07-18 20:54:48
On Tue, 17 Jul 2018, Arnd Bergmann wrote:
That would definitely help. See below for the stat implementation
I did in my musl libc prototype based on statx(). It passes the
LTP syscall tests, but that doesn't mean all the corner cases
are correct.
Well, you definitely need explicit timestamp conversions on the result of
statx to be usable in struct stat when userspace "long" is 64-bit, for BE
because otherwise the integer nanoseconds will be in the wrong place for
struct timespec, and for LE if the "__reserved is held in case we need a
yet finer resolution." might start being returned as nonzero (for integer
attoseconds, I suppose) in future.
--
Joseph S. Myers
joseph@codesourcery.com
On Wed, Jul 18, 2018 at 10:15 PM, Joseph Myers [off-list ref] wrote:
On Tue, 17 Jul 2018, Arnd Bergmann wrote:
quoted
That would definitely help. See below for the stat implementation
I did in my musl libc prototype based on statx(). It passes the
LTP syscall tests, but that doesn't mean all the corner cases
are correct.
Well, you definitely need explicit timestamp conversions on the result of
statx to be usable in struct stat when userspace "long" is 64-bit, for BE
because otherwise the integer nanoseconds will be in the wrong place for
struct timespec, and for LE if the "__reserved is held in case we need a
yet finer resolution." might start being returned as nonzero (for integer
attoseconds, I suppose) in future.
Right. The musl implementation I sent did that by simply copying each
field we care about from the statx structure into the stat structure
individually. This is the more or less the same thing that the kernel
does to implement stat() as well.
Arnd
recvmmsg() takes two arguments to pointers of structures that differ
between 32-bit and 64-bit architectures: mmsghdr and timespec.
For y2038 compatbility, we are changing the native system call from
timespec to __kernel_timespec with a 64-bit time_t (in another patch),
and use the existing compat system call on both 32-bit and 64-bit
architectures for compatibility with traditional 32-bit user space.
As we now have two variants of recvmmsg() for 32-bit tasks that are both
different from the variant that we use on 64-bit tasks, this means we
also require two compat system calls!
The solution I picked is to flip things around: The existing
compat_sys_recvmmsg() call gets moved from net/compat.c into net/socket.c
and now handles the case for old user space on all architectures that
have set CONFIG_COMPAT_32BIT_TIME. A new compat_sys_recvmmsg_time64()
call gets added in the old place for 64-bit architectures only, this
one handles the case of a compat mmsghdr structure combined with
__kernel_timespec.
In the indirect sys_socketcall(), we now need to call either
do_sys_recvmmsg() or __compat_sys_recvmmsg(), depending on what kind of
architecture we are on. For compat_sys_socketcall(), no such change is
needed, we always call __compat_sys_recvmmsg().
I decided to not add a new SYS_RECVMMSG_TIME64 socketcall: Any libc
implementation for 64-bit time_t will need significant changes including
an updated asm/unistd.h, and it seems better to consistently use the
separate syscalls that configuration, leaving the socketcall only for
backward compatibility with 32-bit time_t based libc.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/compat.h | 5 ++++-
include/linux/socket.h | 15 ++++++++++++++-
kernel/sys_ni.c | 1 +
net/compat.c | 14 +++++++-------
net/socket.c | 39 +++++++++++++++++++++++++++++++++++++--
5 files changed, 63 insertions(+), 11 deletions(-)