- 19 Feb, 2019 3 commits
-
-
Arnd Bergmann authored
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 <arnd@arndb.de>
-
Yury Norov authored
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 <arnd@arndb.de> 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 <ynorov@caviumnetworks.com> Acked-by:
Yury Norov <ynorov@marvell.com> Signed-off-by:
-
Yury Norov authored
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:
-
- 18 Feb, 2019 1 commit
-
-
Yury Norov authored
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:
-
- 06 Feb, 2019 13 commits
-
-
Arnd Bergmann authored
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:
Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
Catalin Marinas <catalin.marinas@arm.com>
-
Arnd Bergmann authored
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 authored
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 authored
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:
-
Arnd Bergmann authored
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:
-
Arnd Bergmann authored
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: -
Deepa Dinamani authored
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 <deepa.kernel@gmail.com> Signed-off-by:
-
Deepa Dinamani authored
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: -
Arnd Bergmann authored
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 authored
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: 6ff84735 ("time: Change types to new y2038 safe __kernel_itimerspec") Signed-off-by:
-
Deepa Dinamani authored
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:
-
Arnd Bergmann authored
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 authored
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:
-
- 25 Jan, 2019 16 commits
-
-
Arnd Bergmann authored
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 authored
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 authored
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 authored
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 authored
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 authored
__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 authored
statx is available on almost all other architectures but got missed on sh, so add it now. Signed-off-by: -
Arnd Bergmann authored
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: 2b3c5a99 ("sh: generate uapi header and syscall table header files") Signed-off-by:
-
Arnd Bergmann authored
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:
-
Arnd Bergmann authored
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:
-
Arnd Bergmann authored
The migrate_pages system call has an assigned number on all architectures except ARM. When it got added initially in commit d80ade7b ("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 authored
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 everywhere alarm, 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 authored
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 authored
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 authored
All architectures should implement these two, so assign numbers and hook them up on ia64. Signed-off-by: -
Arnd Bergmann authored
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:
-
- 18 Jan, 2019 5 commits
-
-
Arnd Bergmann authored
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.deSigned-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
Arnd Bergmann authored
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.deSigned-off-by:
-
Arnd Bergmann authored
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.deSigned-off-by:
-
Arnd Bergmann authored
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.deSigned-off-by:
-
Arnd Bergmann authored
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 fa697140 ("syscalls/x86: Use 'struct pt_regs' based syscall calling convention for 64-bit syscalls") and 4378a7d4 ("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.deSigned-off-by:
-
- 13 Jan, 2019 2 commits
-
-
Linus Torvalds authored
-
Jonathan Neuschäfer authored
UNAME26 is a mechanism to report Linux's version as 2.6.x, for compatibility with old/broken software. Due to the way it is implemented, it would have to be updated after 5.0, to keep the resulting versions unique. Linus Torvalds argued: "Do we actually need this? I'd rather let it bitrot, and just let it return random versions. It will just start again at 2.4.60, won't it? Anybody who uses UNAME26 for a 5.x kernel might as well think it's still 4.x. The user space is so old that it can't possibly care about differences between 4.x and 5.x, can it? The only thing that matters is that it shows "2.4.<largeenough>", which it will do regardless" Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
