20 Feb, 2019
3 commits
-
mq_timedreceive was spelled incorrectly, and we need exceptions
for new architectures that leave out newstat or stat64, implementing
only statx() now.Fixes: 48166e6ea47d ("y2038: add 64-bit time_t syscalls to all 32-bit architectures")
Fixes: bf4b6a7d371e ("y2038: Remove stat64 family from default syscall set")
Signed-off-by: Arnd Bergmann -
The __ARCH_WANT_STAT64 macro must be defined before including
asm-generic/unistd.h. I got this right for everything except
unicore32.Fixes: bf4b6a7d371e ("y2038: Remove stat64 family from default syscall set")
Signed-off-by: Arnd Bergmann -
We don't want new architectures to even provide the old 32-bit time_t
based system calls any more, or define the syscall number macros.Add a new __ARCH_WANT_TIME32_SYSCALLS macro that gets enabled for all
existing 32-bit architectures using the generic system call table,
so we don't change any current behavior.
Since this symbol is evaluated in user space as well, we cannot use
a Kconfig CONFIG_* macro but have to define it in uapi/asm/unistd.h.On 64-bit architectures, the same system call numbers mostly refer to
the system calls we want to keep, as they already pass 64-bit time_t.As new architectures no longer provide these, we need new exceptions
in checksyscalls.sh.Signed-off-by: Arnd Bergmann
19 Feb, 2019
2 commits
-
The newer prlimit64 syscall provides all the functionality of getrlimit
and setrlimit syscalls and adds the pid of target process, so future
architectures won't need to include getrlimit and setrlimit.Therefore drop getrlimit and setrlimit syscalls from the generic syscall
list unless __ARCH_WANT_SET_GET_RLIMIT is defined by the architecture's
unistd.h prior to including asm-generic/unistd.h, and adjust all
architectures using the generic syscall list to define it so that no
in-tree architectures are affected.Cc: Arnd Bergmann
Cc: linux-arch@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-hexagon@vger.kernel.org
Cc: uclinux-h8-devel@lists.sourceforge.jp
Signed-off-by: Yury Norov
Acked-by: Arnd Bergmann
Acked-by: Mark Salter [c6x]
Acked-by: James Hogan [metag]
Acked-by: Ley Foon Tan [nios2]
Acked-by: Stafford Horne [openrisc]
Acked-by: Will Deacon [arm64]
Acked-by: Vineet Gupta #arch/arc bits
Signed-off-by: Yury Norov
Signed-off-by: Arnd Bergmann -
All new 32-bit architectures should have 64-bit userspace off_t type, but
existing architectures has 32-bit ones.To enforce the rule, new config option is added to arch/Kconfig that defaults
ARCH_32BIT_OFF_T to be disabled for new 32-bit architectures. All existing
32-bit architectures enable it explicitly.New option affects force_o_largefile() behaviour. Namely, if userspace
off_t is 64-bits long, we have no reason to reject user to open big files.Note that even if architectures has only 64-bit off_t in the kernel
(arc, c6x, h8300, hexagon, nios2, openrisc, and unicore32),
a libc may use 32-bit off_t, and therefore want to limit the file size
to 4GB unless specified differently in the open flags.Signed-off-by: Yury Norov
Acked-by: Arnd Bergmann
Signed-off-by: Yury Norov
Signed-off-by: Arnd Bergmann
18 Feb, 2019
1 commit
-
The only difference between native and compat openat and open_by_handle_at
is that non-compat version forces O_LARGEFILE, and it should be the
default behaviour for all architectures, as we are going to drop the
support of 32-bit userspace off_t.Signed-off-by: Yury Norov
Signed-off-by: Yury Norov
Signed-off-by: Arnd Bergmann
07 Feb, 2019
13 commits
-
This adds 21 new system calls on each ABI that has 32-bit time_t
today. All of these have the exact same semantics as their existing
counterparts, and the new ones all have macro names that end in 'time64'
for clarification.This gets us to the point of being able to safely use a C library
that has 64-bit time_t in user space. There are still a couple of
loose ends to tie up in various areas of the code, but this is the
big one, and should be entirely uncontroversial at this point.In particular, there are four system calls (getitimer, setitimer,
waitid, and getrusage) that don't have a 64-bit counterpart yet,
but these can all be safely implemented in the C library by wrapping
around the existing system calls because the 32-bit time_t they
pass only counts elapsed time, not time since the epoch. They
will be dealt with later.Signed-off-by: Arnd Bergmann
Acked-by: Heiko Carstens
Acked-by: Geert Uytterhoeven
Acked-by: Catalin Marinas -
The time, stime, utime, utimes, and futimesat system calls are only
used on older architectures, and we do not provide y2038 safe variants
of them, as they are replaced by clock_gettime64, clock_settime64,
and utimensat_time64.However, for consistency it seems better to have the 32-bit architectures
that still use them call the "time32" entry points (leaving the
traditional handlers for the 64-bit architectures), like we do for system
calls that now require two versions.Note: We used to always define __ARCH_WANT_SYS_TIME and
__ARCH_WANT_SYS_UTIME and only set __ARCH_WANT_COMPAT_SYS_TIME and
__ARCH_WANT_SYS_UTIME32 for compat mode on 64-bit kernels. Now this is
reversed: only 64-bit architectures set __ARCH_WANT_SYS_TIME/UTIME, while
we need __ARCH_WANT_SYS_TIME32/UTIME32 for 32-bit architectures and compat
mode. The resulting asm/unistd.h changes look a bit counterintuitive.This is only a cleanup patch and it should not change any behavior.
Signed-off-by: Arnd Bergmann
Acked-by: Geert Uytterhoeven
Acked-by: Heiko Carstens -
We now use 64-bit time_t on all architectures, so the __kernel_timex,
__kernel_timeval and __kernel_timespec redirects can be removed
after having served their purpose.This makes it all much less confusing, as the __kernel_* types
now always refer to the same layout based on 64-bit time_t across
all 32-bit and 64-bit architectures.Signed-off-by: Arnd Bergmann
-
This is the big flip, where all 32-bit architectures set COMPAT_32BIT_TIME
and use the _time32 system calls from the former compat layer instead
of the system calls that take __kernel_timespec and similar arguments.The temporary redirects for __kernel_timespec, __kernel_itimerspec
and __kernel_timex can get removed with this.It would be easy to split this commit by architecture, but with the new
generated system call tables, it's easy enough to do it all at once,
which makes it a little easier to check that the changes are the same
in each table.Acked-by: Geert Uytterhoeven
Signed-off-by: Arnd Bergmann -
A lot of system calls that pass a time_t somewhere have an implementation
using a COMPAT_SYSCALL_DEFINEx() on 64-bit architectures, and have
been reworked so that this implementation can now be used on 32-bit
architectures as well.The missing step is to redefine them using the regular SYSCALL_DEFINEx()
to get them out of the compat namespace and make it possible to build them
on 32-bit architectures.Any system call that ends in 'time' gets a '32' suffix on its name for
that version, while the others get a '_time32' suffix, to distinguish
them from the normal version, which takes a 64-bit time argument in the
future.In this step, only 64-bit architectures are changed, doing this rename
first lets us avoid touching the 32-bit architectures twice.Acked-by: Catalin Marinas
Signed-off-by: Arnd Bergmann -
x32 has always followed the time64 calling conventions of these
syscalls, which required a special hack in compat_get_timespec
aka get_old_timespec32 to continue working.Since we now have the time64 syscalls, use those explicitly.
Signed-off-by: Arnd Bergmann
-
struct timex is not y2038 safe.
Switch all the syscall apis to use y2038 safe __kernel_timex.Note that sys_adjtimex() does not have a y2038 safe solution. C libraries
can implement it by calling clock_adjtime(CLOCK_REALTIME, ...).Signed-off-by: Deepa Dinamani
Signed-off-by: Arnd Bergmann -
struct timex is not y2038 safe.
Replace all uses of timex with y2038 safe __kernel_timex.Note that struct __kernel_timex is an ABI interface definition.
We could define a new structure based on __kernel_timex that
is only available internally instead. Right now, there isn't
a strong motivation for this as the structure is isolated to
a few defined struct timex interfaces and such a structure would
be exactly the same as struct timex.The patch was generated by the following coccinelle script:
virtual patch
@depends on patch forall@
identifier ts;
expression e;
@@
(
- struct timex ts;
+ struct __kernel_timex ts;
|
- struct timex ts = {};
+ struct __kernel_timex ts = {};
|
- struct timex ts = e;
+ struct __kernel_timex ts = e;
|
- struct timex *ts;
+ struct __kernel_timex *ts;
|
(memset \| copy_from_user \| copy_to_user \)(...,
- sizeof(struct timex))
+ sizeof(struct __kernel_timex))
)@depends on patch forall@
identifier ts;
identifier fn;
@@
fn(...,
- struct timex *ts,
+ struct __kernel_timex *ts,
...) {
...
}@depends on patch forall@
identifier ts;
identifier fn;
@@
fn(...,
- struct timex *ts) {
+ struct __kernel_timex *ts) {
...
}Signed-off-by: Deepa Dinamani
Cc: linux-alpha@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Arnd Bergmann -
sparc64 is the only architecture on Linux that has a 'timeval'
definition with a 32-bit tv_usec but a 64-bit tv_sec. This causes
problems for sparc32 compat mode when we convert it to use the
new __kernel_timex type that has the same layout as all other
64-bit architectures.To avoid adding sparc64 specific code into the generic adjtimex
implementation, this adds a wrapper in the sparc64 system call handling
that converts the sparc64 'timex' into the new '__kernel_timex'.At this point, the two structures are defined to be identical,
but that will change in the next step once we convert sparc32.Signed-off-by: Arnd Bergmann
-
A small typo has crept into the y2038 conversion of the timer_settime
system call. So far this was completely harmless, but once we start
using the new version, this has to be fixed.Fixes: 6ff847350702 ("time: Change types to new y2038 safe __kernel_itimerspec")
Signed-off-by: Arnd Bergmann -
struct timex uses struct timeval internally.
struct timeval is not y2038 safe.
Introduce a new UAPI type struct __kernel_timex
that is y2038 safe.struct __kernel_timex uses a timeval type that is
similar to struct __kernel_timespec which preserves the
same structure size across 32 bit and 64 bit ABIs.
struct __kernel_timex also restructures other members of the
structure to make the structure the same on 64 bit and 32 bit
architectures.
Note that struct __kernel_timex is the same as struct timex
on a 64 bit architecture.The above solution is similar to other new y2038 syscalls
that are being introduced: both 32 bit and 64 bit ABIs
have a common entry, and the compat entry supports the old 32 bit
syscall interface.Alternatives considered were:
1. Add new time type to struct timex that makes use of padded
bits. This time type could be based on the struct __kernel_timespec.
modes will use a flag to notify which time structure should be
used internally.
This needs some application level changes on both 64 bit and 32 bit
architectures. Although 64 bit machines could continue to use the
older timeval structure without any changes.2. Add a new u8 type to struct timex that makes use of padded bits. This
can be used to save higher order tv_sec bits. modes will use a flag to
notify presence of such a type.
This will need some application level changes on 32 bit architectures.3. Add a new compat_timex structure that differs in only the size of the
time type; keep rest of struct timex the same.
This requires extra syscalls to manage all 3 cases on 64 bit
architectures. This will not need any application level changes but will
add more complexity from kernel side.Signed-off-by: Deepa Dinamani
Signed-off-by: Arnd Bergmann -
We want to reuse the compat_timex handling on 32-bit architectures the
same way we are using the compat handling for timespec when moving to
64-bit time_t.Move all definitions related to compat_timex out of the compat code
into the normal timekeeping code, along with a rename to old_timex32,
corresponding to the timespec/timeval structures, and make it controlled
by CONFIG_COMPAT_32BIT_TIME, which 32-bit architectures will then select.Signed-off-by: Arnd Bergmann
-
These are all for ignoring the lack of obsolete system calls,
which have been marked the same way in scripts/checksyscall.sh,
so these can be removed.Signed-off-by: Arnd Bergmann
Acked-by: Heiko Carstens
26 Jan, 2019
16 commits
-
Alpha has traditionally followed the OSF1 calling conventions
here, with its getxpid, getxuid, getxgid system calls returning
two different values in separate registers.Following what glibc has done here, we can define getpid,
getuid and getgid to be aliases for getxpid, getxuid and getxgid
respectively, and add new system call numbers for getppid, geteuid
and getegid.Signed-off-by: Arnd Bergmann
-
As Joseph Myers points out, alpha has never had a standard statfs64
interface and instead returns only 32-bit numbers here.While there is an old osf_statfs64 system call that returns additional
data, this has some other quirks and does not get used in glibc.I considered making the stat64 structure layout compatible with
with the one used by the kernel on most other 64 bit architecture that
implement it (ia64, parisc, powerpc, and sparc), but in the end
decided to stay with the one that was traditionally defined in
the alpha headers but not used, since this is also what glibc
exposes to user space.Signed-off-by: Arnd Bergmann
-
Most architectures define system call numbers for the rseq and pkey system
calls, even when they don't support the features, and perhaps never will.Only a few architectures are missing these, so just define them anyway
for consistency. If we decide to add them later to one of these, the
system call numbers won't get out of sync then.Signed-off-by: Arnd Bergmann
Acked-by: Heiko Carstens
Acked-by: Geert Uytterhoeven -
The IPC system call handling is highly inconsistent across architectures,
some use sys_ipc, some use separate calls, and some use both. We also
have some architectures that require passing IPC_64 in the flags, and
others that set it implicitly.For the addition of a y2038 safe semtimedop() system call, I chose to only
support the separate entry points, but that requires first supporting
the regular ones with their own syscall numbers.The IPC_64 is now implied by the new semctl/shmctl/msgctl system
calls even on the architectures that require passing it with the ipc()
multiplexer.I'm not adding the new semtimedop() or semop() on 32-bit architectures,
those will get implemented using the new semtimedop_time64() version
that gets added along with the other time64 calls.
Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop().Signed-off-by: Arnd Bergmann
Acked-by: Geert Uytterhoeven
Acked-by: Heiko Carstens -
The behavior of these system calls is slightly different between
architectures, as determined by the CONFIG_ARCH_WANT_IPC_PARSE_VERSION
symbol. Most architectures that implement the split IPC syscalls don't set
that symbol and only get the modern version, but alpha, arm, microblaze,
mips-n32, mips-n64 and xtensa expect the caller to pass the IPC_64 flag.For the architectures that so far only implement sys_ipc(), i.e. m68k,
mips-o32, powerpc, s390, sh, sparc, and x86-32, we want the new behavior
when adding the split syscalls, so we need to distinguish between the
two groups of architectures.The method I picked for this distinction is to have a separate system call
entry point: sys_old_*ctl() now uses ipc_parse_version, while sys_*ctl()
does not. The system call tables of the five architectures are changed
accordingly.As an additional benefit, we no longer need the configuration specific
definition for ipc_parse_version(), it always does the same thing now,
but simply won't get called on architectures with the modern interface.A small downside is that on architectures that do set
ARCH_WANT_IPC_PARSE_VERSION, we now have an extra set of entry points
that are never called. They only add a few bytes of bloat, so it seems
better to keep them compared to adding yet another Kconfig symbol.
I considered adding new syscall numbers for the IPC_64 variants for
consistency, but decided against that for now.Signed-off-by: Arnd Bergmann
-
__kernel_timespec and timespec are currently the same type, but once
they are different, the type cast has to be changed here.Signed-off-by: Arnd Bergmann
-
statx is available on almost all other architectures but
got missed on sh, so add it now.Signed-off-by: Arnd Bergmann
-
When I merged this patch, the file was accidentally left intact
instead of being removed, which means any changes to syscall.tbl
have no effect.Fixes: 2b3c5a99d5f3 ("sh: generate uapi header and syscall table header files")
Signed-off-by: Arnd Bergmann -
Most architectures have assigned a numbers for the seccomp syscall
even when they do not implement it.m68k is an exception here, so for consistency lets add the number.
Unless CONFIG_SECCOMP is implemented, the system call just
returns -ENOSYS.Acked-by: Geert Uytterhoeven
Signed-off-by: Arnd Bergmann -
A couple of architectures including arm64 already implement the
kexec_file_load system call, on many others we have assigned a system
call number for it, but not implemented it yet.Adding the number in arch/arm/ lets us use the system call on arm64
systems in compat mode, and also reduces the number of differences
between architectures. If we want to implement kexec_file_load on ARM
in the future, the number assignment means that kexec tools can already
be built with the now current set of kernel headers.Acked-by: Catalin Marinas
Signed-off-by: Arnd Bergmann -
The migrate_pages system call has an assigned number on all architectures
except ARM. When it got added initially in commit d80ade7b3231 ("ARM:
Fix warning: #warning syscall migrate_pages not implemented"), it was
intentionally left out based on the observation that there are no 32-bit
ARM NUMA systems.However, there are now arm64 NUMA machines that can in theory run 32-bit
kernels (actually enabling NUMA there would require additional work)
as well as 32-bit user space on 64-bit kernels, so that argument is no
longer very strong.Assigning the number lets us use the system call on 64-bit kernels as well
as providing a more consistent set of syscalls across architectures.Signed-off-by: Arnd Bergmann
Acked-by: Catalin Marinas -
Other architectures commonly use __NR_umount2 for sys_umount,
only ia64 and alpha use __NR_umount here. In order to synchronize
the generated tables, use umount2 like everyone else, and add back
the old name from asm/unistd.h for compatibility.For shmat, alpha uses the osf_shmat name, we can do the same thing
here, which means we don't have to add an entry in the __IGNORE
list now that shmat is mandatory everywherealarm, creat, pause, time, and utime are optional everywhere
these days, no need to list them here any more.I considered also adding the regular versions of the get*id system
calls that have different names and calling conventions on alpha,
which would further help unify the syscall ABI, but for now
I decided against that.Signed-off-by: Arnd Bergmann
-
The io_pgetevents system call was added in linux-4.18 but has
no entry for alpha:warning: #warning syscall io_pgetevents not implemented [-Wcpp]
Assign a the next system call number here.
Cc: stable@vger.kernel.org
Signed-off-by: Arnd Bergmann -
Most architectures have assigned numbers for both seccomp and
perf_event_open, even when they do not implement either.ia64 is an exception here, so for consistency lets add numbers for both
of them. Unless CONFIG_PERF_EVENTS and CONFIG_SECCOMP are implemented,
the system calls just return -ENOSYS.Signed-off-by: Arnd Bergmann
-
All architectures should implement these two, so assign numbers
and hook them up on ia64.Signed-off-by: Arnd Bergmann
-
Other architectures commonly use __NR_umount2 for sys_umount,
only ia64 and alpha use __NR_umount here. In order to synchronize
the generated tables, use umount2 like everyone else, and add back
the old name from asm/unistd.h for compatibility.The __IGNORE_* lines are now all obsolete and can be removed as
a side-effect.Signed-off-by: Arnd Bergmann
18 Jan, 2019
5 commits
-
Now that all these wrappers are automatically generated, we can
remove the entire file, and instead point to the regualar syscalls
like all other architectures do.The 31-bit pointer extension is now handled in the __s390_sys_*()
wrappers.Link: https://lore.kernel.org/lkml/20190116131527.2071570-6-arnd@arndb.de
Signed-off-by: Arnd Bergmann
Reviewed-by: Heiko Carstens
Signed-off-by: Heiko Carstens
Signed-off-by: Martin Schwidefsky -
Any system call that takes a pointer argument on s390 requires
a wrapper function to do a 31-to-64 zero-extension, these are
currently generated in arch/s390/kernel/compat_wrapper.c.On arm64 and x86, we already generate similar wrappers for all
system calls in the place of their definition, just for a different
purpose (they load the arguments from pt_regs).We can do the same thing here, by adding an asm/syscall_wrapper.h
file with a copy of all the relevant macros to override the generic
version. Besides the addition of the compat entry point, these also
rename the entry points with a __s390_ or __s390x_ prefix, similar
to what we do on arm64 and x86. This in turn requires renaming
a few things, and adding a proper ni_syscall() entry point.In order to still compile system call definitions that pass an
loff_t argument, the __SC_COMPAT_CAST() macro checks for that
and forces an -ENOSYS error, which was the best I could come up
with. Those functions must obviously not get called from user
space, but instead require hand-written compat_sys_*() handlers,
which fortunately already exist.Link: https://lore.kernel.org/lkml/20190116131527.2071570-5-arnd@arndb.de
Signed-off-by: Arnd Bergmann
Reviewed-by: Heiko Carstens
[heiko.carstens@de.ibm.com: compile fix for !CONFIG_COMPAT]
Signed-off-by: Heiko Carstens
Signed-off-by: Martin Schwidefsky -
s390 has an almost identical copy of the code in kernel/uid16.c.
The problem here is that it requires calling the regular system calls,
which the generic implementation handles correctly, but the internal
interfaces are not declared in a global header for this.The best way forward here seems to be to just use the generic code and
delete the s390 specific implementation.I keep the changes to uapi/asm/posix_types.h inside of an #ifdef check
so user space does not observe any changes. As some of the system calls
pass pointers, we also need wrappers in compat_wrapper.c, which I add
for all calls with at least one argument. All those wrappers can be
removed in a later step.Link: https://lore.kernel.org/lkml/20190116131527.2071570-4-arnd@arndb.de
Signed-off-by: Arnd Bergmann
Reviewed-by: Heiko Carstens
Signed-off-by: Heiko Carstens
Signed-off-by: Martin Schwidefsky -
The sys_ipc() and compat_ksys_ipc() functions are meant to only
be used from the system call table, not called by another function.Introduce ksys_*() interfaces for this purpose, as we have done
for many other system calls.Link: https://lore.kernel.org/lkml/20190116131527.2071570-3-arnd@arndb.de
Signed-off-by: Arnd Bergmann
Reviewed-by: Heiko Carstens
[heiko.carstens@de.ibm.com: compile fix for !CONFIG_COMPAT]
Signed-off-by: Heiko Carstens
Signed-off-by: Martin Schwidefsky -
Patch series "s390: rework compat wrapper generation".
As promised, I gave this a go and changed the SYSCALL_DEFINEx()
infrastructure to always include the wrappers for doing the
31-bit argument conversion on s390 compat mode.This does three main things:
- The UID16 rework saved a lot of duplicated code, and would
probably make sense by itself, but is also required as
we can no longer call sys_*() functions directly after the
last step.- Removing the compat_wrapper.c file is of course the main
goal here, in order to remove the need to maintain the
compat_wrapper.c file when new system calls get added.
Unfortunately, this requires adding some complexity in
syscall_wrapper.h, and trades a small reduction in source
code lines for a small increase in binary size for
unused wrappers.- As an added benefit, the use of syscall_wrapper.h now makes
it easy to change the syscall wrappers so they no longer
see all user space register contents, similar to changes
done in commits fa697140f9a2 ("syscalls/x86: Use 'struct pt_regs'
based syscall calling convention for 64-bit syscalls") and
4378a7d4be30 ("arm64: implement syscall wrappers").
I leave the actual implementation of this for you, if you
want to do it later.I did not test the changes at runtime, but I looked at the
generated object code, which seems fine here and includes
the same conversions as before.This patch(of 5):
The sys_personality function is not meant to be called from other system
calls. We could introduce an intermediate ksys_personality function,
but it does almost nothing, so this just moves the implementation into
the caller.Link: https://lore.kernel.org/lkml/20190116131527.2071570-1-arnd@arndb.de
Link: https://lore.kernel.org/lkml/20190116131527.2071570-2-arnd@arndb.de
Signed-off-by: Arnd Bergmann
Reviewed-by: Heiko Carstens
Signed-off-by: Heiko Carstens
Signed-off-by: Martin Schwidefsky