about summary refs log tree commit diff
path: root/sysdeps/unix/sysv
Commit message (Collapse)AuthorAgeFilesLines
* semctl: Remove the sem-pad.h fileAlistair Francis2020-04-2911-117/+141
| | | | | | | Remove the sem-pad.h file and instead have architectures override the struct semid_ds via the bits/types/struct_semid_ds.h file. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* bits/sem.h: Split out struct semid_dsAlistair Francis2020-04-293-23/+45
| | | | | | | Split out the struct semid_ds into it's own file. This will allow us to have architectures specify their own version. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Mark unsigned long arguments with U in more syscalls [BZ #25810]H.J. Lu2020-04-291-11/+11
| | | | | | | Mark unsigned long arguments in mmap, read, recv, recvfrom, send, sendto, write, ioperm, sendfile64, setxattr, lsetxattr, fsetxattr, getxattr, lgetxattr, fgetxattr, listxattr, llistxattr and flistxattr with U in syscalls.list files.
* Add SYSCALL_ULONG_ARG_[12] to pass long to syscall [BZ #25810]H.J. Lu2020-04-293-23/+85
| | | | | | | | | | | | | | | | | | | X32 has 32-bit long and pointer with 64-bit off_t. Since x32 psABI requires that pointers passed in registers must be zero-extended to 64bit, x32 can share many syscall interfaces with LP64. When a LP64 syscall with long and unsigned long int arguments is used for x32, these arguments must be properly extended to 64-bit. Otherwise if the upper 32 bits of the register have undefined value, such a syscall will be rejected by kernel. For syscalls implemented in assembly codes, 'U' is added to syscall signature key letters for unsigned long, which is zero-extended to 64-bit types. SYSCALL_ULONG_ARG_1 and SYSCALL_ULONG_ARG_2 are passed to syscall-template.S for the first and the second unsigned long int arguments if PSEUDOS_HAVE_ULONG_INDICES is defined. They are used by x32 to zero-extend 32-bit arguments to 64 bits. Tested on i386, x86-64 and x32 as well as with build-many-glibcs.py.
* signal: Only handle on NSIG signals on signal functions (BZ #25657)Adhemerval Zanella2020-04-212-83/+78
| | | | | | | | | | | | | | | The upper bits of the sigset_t s not fully initialized in the signal mask calls that return information from kernel (sigprocmask, sigpending, and pthread_sigmask), since the exported sigset_t size (1024 bits) is larger than Linux support one (64 or 128 bits). It might make sigisemptyset/sigorset/sigandset fail if the mask is filled prior the call. This patch changes the internal signal function to handle up to supported Linux signal number (_NSIG), the remaining bits are untouched. Checked on x86_64-linux-gnu and i686-linux-gnu.
* linux: Use pthread_sigmask on sigprocmaskAdhemerval Zanella2020-04-212-15/+24
| | | | | | | With pthread_sigmask on libc.so, it allows implement sigprocmask on top of pthread_sigmask. Checked on x86_64-linux-gnu.
* ia64: Remove sigprocmask/sigblock objects from libpthreadAdhemerval Zanella2020-04-211-2/+1
| | | | | | | | | | | | | It is required because __libc_unwind_longjmp (used on thread cancellation) calls __sigprocmask. Replace with a direct call. They are required because __libc_unwind_longjmp (used for thread cancellation) calls __sigprocmask. Replace this with a direct call. The sigblock function is not exported and is not used internally, so it can be removed. Checked on cross build for ia64-linux-gnu.
* nptl: Move pthread_sigmask implementation to libcAdhemerval Zanella2020-04-2158-30/+63
| | | | | | | | | | | This is part of the libpthread removal project: <https://sourceware.org/ml/libc-alpha/2019-10/msg00080.html> A new symbol version is added on libc to force loading failure instead of lazy binding one for newly binaries with old loaders. Checked with a build against all affected ABIs.
* ARC: Update syscall-names.list for ARC specific syscallsVineet Gupta2020-04-201-0/+3
|
* provide y2038 safe socket constants for default/asm-generic ABIVineet Gupta2020-04-191-2/+14
| | | | | | | These will be used by upcoming RV32 and ARC ports and any future ports. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
* i686: Add INTERNAL_SYSCALL_NCS 6 argument supportAdhemerval Zanella2020-04-171-30/+49
| | | | | | | | It is required for i686 BZ#12683 support when building with -Os or -fno-omit-frame-pointer on some gcc versions. It is not used on current code. Check on i686-linux-gnu.
* Linux: Remove <sys/sysctl.h> and the sysctl functionFlorian Weimer2020-04-1510-124/+46
| | | | | | | | | | | | | | | Linux 5.5 remove the system call in commit 61a47c1ad3a4dc6882f01ebdc88138ac62d0df03 ("Linux: Remove <sys/sysctl.h>"). Therefore, the compat function is just a stub that sets ENOSYS. Due to SHLIB_COMPAT, new ports will not add the sysctl function anymore automatically. x32 already lacks the sysctl function, so an empty sysctl.c file is used to suppress it. Otherwise, a new compat symbol would be added. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* linux: wait4: Fix incorrect return value comparisonAlistair Francis2020-04-141-10/+9
| | | | | | | | | | Patch 600f00b "linux: Use long time_t for wait4/getrusage" introduced two bugs: - The usage32 struct was set if the wait4 syscall had an error. - For 32-bit systems the usage struct was set even if it was specified as NULL. This patch fixes the two issues.
* x32: Properly pass long to syscall [BZ #25810]H.J. Lu2020-04-132-6/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | X32 has 32-bit long and pointer with 64-bit off_t. Since x32 psABI requires that pointers passed in registers must be zero-extended to 64bit, x32 can share many syscall interfaces with LP64. When a LP64 syscall with long and unsigned long arguments is used for x32, these arguments must be properly extended to 64-bit. Otherwise if the upper 32 bits of the register have undefined value, such a syscall will be rejected by kernel. Enforce zero-extension for pointers and array system call arguments. For integer types, extend to int64_t (the full register) using a regular cast, resulting in zero or sign extension based on the signedness of the original type. For void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset); we now generate 0: 41 f7 c1 ff 0f 00 00 test $0xfff,%r9d 7: 75 1f jne 28 <__mmap64+0x28> 9: 48 63 d2 movslq %edx,%rdx c: 89 f6 mov %esi,%esi e: 4d 63 c0 movslq %r8d,%r8 11: 4c 63 d1 movslq %ecx,%r10 14: b8 09 00 00 40 mov $0x40000009,%eax 19: 0f 05 syscall That is 1. addr is unchanged. 2. length is zero-extend to 64 bits. 3. prot is sign-extend to 64 bits. 4. flags is sign-extend to 64 bits. 5. fd is sign-extend to 64 bits. 6. offset is unchanged. For int arguments, since kernel uses only the lower 32 bits and ignores the upper 32 bits in 64-bit registers, these work correctly. Tested on x86-64 and x32. There are no code changes on x86-64.
* Update kernel version to 5.6 in tst-mman-consts.py.Joseph Myers2020-04-091-1/+1
| | | | | | | | This patch updates the kernel version in the test tst-mman-consts.py to 5.6. (There are no new constants covered by this test in 5.6 that need any other header changes.) Tested with build-many-glibcs.py.
* i386: Remove build support for GCC older than GCC 6H.J. Lu2020-04-071-16/+1
| | | | | | | | | Since GCC 6.2 or later is required to build glibc, remove build support for GCC older than GCC 6. Testd with GCC 6.4 and GCC 9.3. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* y2038: linux: Provide __mq_timedreceive_time64 implementationLukasz Majewski2020-04-061-4/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides new __mq_timedreceive_time64 explicit 64 bit function for receiving messages with absolute timeout. Moreover, a 32 bit version - __mq_timedreceive has been refactored to internally use __mq_timedreceive_time64. The __mq_timedreceive is now supposed to be used on systems still supporting 32 bit time (__TIMESIZE != 64) - hence the necessary conversion to 64 bit struct __timespec64 from struct timespec. The new mq_timedsend_time64 syscall available from Linux 5.1+ has been used, when applicable. As this wrapper function is also used internally in the glibc, to e.g. provide mq_receive implementation, an explicit check for abs_timeout being NULL has been added due to conversions between struct timespec and struct __timespec64. Before this change the Linux kernel handled this NULL pointer. Build tests: - ./src/scripts/build-many-glibcs.py glibcs Run-time tests: - Run specific tests on ARM/x86 32bit systems (qemu): https://github.com/lmajewski/meta-y2038 and run tests: https://github.com/lmajewski/y2038-tests/commits/master Linux kernel, headers and minimal kernel version for glibc build test matrix: - Linux v5.1 (with mq_timedreceive_time64) and glibc built with v5.1 as minimal kernel version (--enable-kernel="5.1.0") The __ASSUME_TIME64_SYSCALLS flag defined. - Linux v5.1 and default minimal kernel version The __ASSUME_TIME64_SYSCALLS not defined, but kernel supports mq_timedreceive_time64 syscall. - Linux v4.19 (no mq_timedreceive_time64 support) with default minimal kernel version for contemporary glibc (3.2.0) This kernel doesn't support mq_timedreceive_time64 syscall, so the fallback to mq_timedreceive is tested. Above tests were performed with Y2038 redirection applied as well as without (so the __TIMESIZE != 64 execution path is checked as well). Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* y2038: linux: Provide __mq_timedsend_time64 implementationLukasz Majewski2020-04-061-3/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides new __mq_timedsend_time64 explicit 64 bit function for sending messages with absolute timeout. Moreover, a 32 bit version - __mq_timedsend has been refactored to internally use __mq_timedsend_time64. The __mq_timedsend is now supposed to be used on systems still supporting 32 bit time (__TIMESIZE != 64) - hence the necessary conversion to 64 bit struct __timespec64 from struct timespec. The new __mq_timedsend_time64 syscall available from Linux 5.1+ has been used, when applicable. As this wrapper function is also used internally in the glibc, to e.g. provide mq_send implementation, an explicit check for abs_timeout being NULL has been added due to conversions between struct timespec and struct __timespec64. Before this change the Linux kernel handled this NULL pointer. Build tests: - ./src/scripts/build-many-glibcs.py glibcs Run-time tests: - Run specific tests on ARM/x86 32bit systems (qemu): https://github.com/lmajewski/meta-y2038 and run tests: https://github.com/lmajewski/y2038-tests/commits/master Linux kernel, headers and minimal kernel version for glibc build test matrix: - Linux v5.1 (with mq_timedsend_time64) and glibc built with v5.1 as a minimal kernel version (--enable-kernel="5.1.0") The __ASSUME_TIME64_SYSCALLS flag defined. - Linux v5.1 and default minimal kernel version The __ASSUME_TIME64_SYSCALLS not defined, but kernel supports mq_timedsend_time64 syscall. - Linux v4.19 (no mq_timedsend_time64 support) with default minimal kernel version for contemporary glibc (3.2.0) This kernel doesn't support mq_timedsend_time64 syscall, so the fallback to mq_timedsend is tested. Above tests were performed with Y2038 redirection applied as well as without (so the __TIMESIZE != 64 execution path is checked as well). Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* i386: Disable check_consistency for GCC 5 and above [BZ #25788]H.J. Lu2020-04-061-2/+3
| | | | | | | check_consistency should be disabled for GCC 5 and above since there is no fixed PIC register in GCC 5 and above. Check __GNUC_PREREQ (5,0) instead OPTIMIZE_FOR_GCC_5 since OPTIMIZE_FOR_GCC_5 is false with -fno-omit-frame-pointer.
* Update syscall lists for Linux 5.6.Joseph Myers2020-04-0324-2/+54
| | | | | | | Linux 5.6 has new openat2 and pidfd_getfd syscalls. This patch adds them to syscall-names.list and regenerates the arch-syscall.h files. Tested with build-many-glibcs.py.
* nptl: Remove x86_64 cancellation assembly implementations [BZ #25765]Adhemerval Zanella2020-04-033-146/+0
| | | | | | | | | All cancellable syscalls are done by C implementations, so there is no no need to use a specialized implementation to optimize register usage. It fixes BZ #25765. Checked on x86_64-linux-gnu.
* aarch64: update bits/hwcap.hSzabolcs Nagy2020-04-031-0/+18
| | | | | Up to date with Linux 5.6. dl-procinfo.c is not updated because HWCAP2 bits are not handled specially in glibc.
* sysv/alpha: Use generic __timeval32 and helpersAlistair Francis2020-04-0210-162/+67
| | | | | | | | Now there is a generic __timeval32 and helpers we can use them for Alpha instead of the Alpha specific ones. Reviewed-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* linux: Use long time_t for wait4/getrusageAlistair Francis2020-04-023-2/+153
| | | | | | | | | | | | | | The Linux kernel expects rusage to use a 32-bit time_t, even on archs with a 64-bit time_t (like RV32). To address this let's convert rusage to/from 32-bit and 64-bit to ensure the kernel always gets a 32-bit time_t. While we are converting these functions let's also convert them to be the y2038 safe versions. This means there is a *64 function that is called by a backwards compatible wrapper. Reviewed-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* linux: Use long time_t __getitimer/__setitimerAlistair Francis2020-04-023-0/+182
| | | | | | | | | | | | | | The Linux kernel expects itimerval to use a 32-bit time_t, even on archs with a 64-bit time_t (like RV32). To address this let's convert itimerval to/from 32-bit and 64-bit to ensure the kernel always gets a 32-bit time_t. While we are converting these functions let's also convert them to be the y2038 safe versions. This means there is a *64 function that is called by a backwards compatible wrapper. Tested-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* sysv: Define __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64Alistair Francis2020-04-025-0/+26
| | | | | | | | | | | | | | | | | | | On y2038 safe 32-bit systems the Linux kernel expects itimerval and rusage to use a 32-bit time_t, even though the other time_t's are 64-bit. There are currently no plans to make 64-bit time_t versions of these structs. There are also other occurrences where the time passed to the kernel via timeval doesn't match the wordsize. To handle these cases let's define a new macro __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64. This macro specifies if the kernel's old_timeval matches the new timeval64. This should be 1 for 64-bit architectures except for Alpha's osf syscalls. The define should be 0 for 32-bit architectures and Alpha's osf syscalls. Reviewed-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Fix data race in setting function descriptors during lazy binding on hppa.John David Anglin2020-03-301-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This addresses an issue that is present mainly on SMP machines running threaded code. In a typical indirect call or PLT import stub, the target address is loaded first. Then the global pointer is loaded into the PIC register in the delay slot of a branch to the target address. During lazy binding, the target address is a trampoline which transfers to _dl_runtime_resolve(). _dl_runtime_resolve() uses the relocation offset stored in the global pointer and the linkage map stored in the trampoline to find the relocation. Then, the function descriptor is updated. In a multi-threaded application, it is possible for the global pointer to be updated between the load of the target address and the global pointer. When this happens, the relocation offset has been replaced by the new global pointer. The function pointer has probably been updated as well but there is no way to find the address of the function descriptor and to transfer to the target. So, _dl_runtime_resolve() typically crashes. HP-UX addressed this problem by adding an extra pc-relative branch to the trampoline. The descriptor is initially setup to point to the branch. The branch then transfers to the trampoline. This allowed the trampoline code to figure out which descriptor was being used without any modification to user code. I didn't use this approach as it is more complex and changes function pointer canonicalization. The order of loading the target address and global pointer in indirect calls was not consistent with the order used in import stubs. In particular, $$dyncall and some inline versions of it loaded the global pointer first. This was inconsistent with the global pointer being updated first in dl-machine.h. Assuming the accesses are ordered, we want elf_machine_fixup_plt() to store the global pointer first and calls to load it last. Then, the global pointer will be correct when the target function is entered. However, just to make things more fun, HP added support for out-of-order execution of accesses in PA 2.0. The accesses used by calls are weakly ordered. So, it's possibly under some circumstances that a function might be entered with the wrong global pointer. However, HP uses weakly ordered accesses in 64-bit HP-UX, so I assume that loading the global pointer in the delay slot of the branch must work consistently. The basic fix for the race is a combination of modifying user code to preserve the address of the function descriptor in register %r22 and setting the least-significant bit in the relocation offset. The latter was suggested by Carlos as a way to distinguish relocation offsets from global pointer values. Conventionally, %r22 is used as the address of the function descriptor in calls to $$dyncall. So, it wasn't hard to preserve the address in %r22. I have updated gcc trunk and gcc-9 branch to not clobber %r22 in $$dyncall and inline indirect calls. I have also modified the import stubs in binutils trunk and the 2.33 branch to preserve %r22. This required making the stubs one instruction longer but we save one relocation. I also modified binutils to align the .plt section on a 8-byte boundary. This allows descriptors to be updated atomically with a floting-point store. With these changes, _dl_runtime_resolve() can fallback to an alternate mechanism to find the relocation offset when it has been clobbered. There's just one additional instruction in the fast path. I tested the fallback function, _dl_fix_reloc_arg(), by changing the branch to always use the fallback. Old code still runs as it did before. Fixes bug 23296. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* sysv/linux: Rename alpha functions to be alpha specificAlistair Francis2020-03-279-32/+32
| | | | | | | | | | | These functions are alpha specifc, rename them to be clear. Let's also rename the header file from tv32-compat.h to alpha-tv32-compat.h. This is to avoid conflicts with the one we will introduce later. Reviewed-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* y2038: fix: Add missing libc_hidden_def attribute for some syscall wrappersLukasz Majewski2020-03-235-0/+10
| | | | | | | | | During the conversion to support 64 bit time on some architectures with __WORDSIZE == 32 && __TIMESIZE != 64 the libc_hidden_def attribute for eligible functions was by mistake omitted. This patch fixes this issue and exports (and allows using) those functions when Y2038 support is enabled in glibc.
* x86: Remove ARCH_CET_LEGACY_BITMAP [BZ #25397]H.J. Lu2020-03-182-25/+0
| | | | | | | | | | | Since legacy bitmap doesn't cover jitted code generated by legacy JIT engine, it isn't very useful. This patch removes ARCH_CET_LEGACY_BITMAP and treats indirect branch tracking similar to shadow stack by removing legacy bitmap support. Tested on CET Linux/x86-64 and non-CET Linux/x86-64. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* mips: Fix wrong INTERNAL_SYSCALL_ERROR_P check from bc2eb9321eAdhemerval Zanella2020-03-101-1/+1
| | | | Checked on mips64-linux-gnu.
* y2038: linux: Provide __futimesat64 implementationLukasz Majewski2020-03-091-13/+28
| | | | | | | | | This conversion patch for supporting 64 bit time for futimesat only differs from the work performed for futimes (when providing __futimes64) with passing also the file name (and path) to utimensat. All the design and conversion decisions are exactly the same as for futimens conversion.
* y2038: linux: Provide __lutimes64 implementationLukasz Majewski2020-03-091-13/+24
| | | | | | | | | | | This conversion patch for supporting 64 bit time for lutimes mostly differs from the work performed for futimes (when providing __futimes64) with adding the AT_SYMLINK_NOFOLLOW flag to utimensat. It also supports passing file name instead of file descriptor number, but this is not relevant for utimensat used to implement it. All the design and conversion decisions are exactly the same as for futimens conversion.
* y2038: linux: Provide __futimes64 implementationLukasz Majewski2020-03-091-19/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides new __futimes64 explicit 64 bit function for setting file's 64 bit attributes for access and modification time (by specifying file descriptor number). Internally, the __utimensat64_helper function is used. This patch is necessary for having architectures with __WORDSIZE == 32 Y2038 safe. Moreover, a 32 bit version - __futimes has been refactored to internally use __futimes64. The __futimes is now supposed to be used on systems still supporting 32 bit time (__TIMESIZE != 64) - hence the necessary conversion of struct timeval to 64 bit struct __timeval64. The check if struct timevals' usec fields are in the range between 0 and 1000000 has been removed as Linux kernel performs it internally in the implementation of utimensat (the conversion between struct __timeval64 and __timespec64 is not relevant for this particular check). Last but not least, checks for tvp{64} not being NULL have been preserved from the original code as some legacy user space programs may rely on it. Build tests: ./src/scripts/build-many-glibcs.py glibcs Run-time tests: - Run specific tests on ARM/x86 32bit systems (qemu): https://github.com/lmajewski/meta-y2038 and run tests: https://github.com/lmajewski/y2038-tests/commits/master Above tests were performed with Y2038 redirection applied as well as without to test the proper usage of both __futimes64 and __futimes.
* y2038: fix: Add missing libc_hidden_def for __futimens64Lukasz Majewski2020-03-071-0/+2
| | | | | The libc_hidden_def () declaration for __futimens64 function was missing, so it is added in this patch.
* sparc: Move sigreturn stub to assemblyAdhemerval Zanella2020-03-065-38/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems that some gcc versions might generates a stack frame for the sigreturn stub requires on sparc signal handling. For instance: $ cat test.c #define _GNU_SOURCE #include <sys/syscall.h> __attribute__ ((__optimize__ ("-fno-stack-protector"))) void __sigreturn_stub (void) { __asm__ ("mov %0, %%g1\n\t" "ta 0x10\n\t" : /* no outputs */ : "i" (SYS_rt_sigreturn)); } $ gcc -v [...] gcc version 9.2.1 20200224 (Debian 9.2.1-30) $ gcc -O2 -m64 test.c -S -o - [...] __sigreturn_stub: save %sp, -176, %sp #APP ! 9 "t.c" 1 mov 101, %g1 ta 0x10 ! 0 "" 2 #NO_APP .size __sigreturn_stub, .-__sigreturn_stub As indicated by kernel developers [1], the sigreturn stub can not change the register window or the stack pointer since the kernel has setup the restore frame at a precise location relative to the stack pointer when the stub is invoked. I tried to play with some compiler flags and even with _Noreturn and __builtin_unreachable after the asm does not help (and Sparc does not support naked functions). To avoid similar issues, as the stack-protector support also have stumbled, this patch moves the implementation of the sigreturn stubs to assembly. Checked on sparcv9-linux-gnu and sparc64-linux-gnu with gcc 9.2.1 and gcc 7.5.0. [1] https://lkml.org/lkml/2016/5/27/465
* linux/sysipc: Include linux/posix_types.h for __kernel_mode_tAdhemerval Zanella2020-03-063-0/+3
| | | | | The posix_types.h (where __kernel_mode_t is defined) is included implicitly, which might not happen on older kernels.
* linux: Clear mode_t padding bits (BZ#25623)Adhemerval Zanella2020-03-053-6/+21
| | | | | | | | | | | | | | | | | | | | The kernel might not clear the padding value for the ipc_perm mode fields in compat mode (32 bit running on a 64 bit kernel). It was fixed on v4.14 when the ipc compat code was refactored to move (commits 553f770ef71b, 469391684626, c0ebccb6fa1e). Although it is most likely a kernel issue, it was shown only due BZ#18231 fix which made all the SysVIPC mode_t 32-bit regardless of the kABI. This patch fixes it by explicitly zeroing the upper bits for such cases. The __ASSUME_SYSVIPC_BROKEN_MODE_T case already handles it with the shift. (The aarch64 ipc_priv.h is superflous since __ASSUME_SYSVIPC_DEFAULT_IPC_64 is now defined as default). Checked on i686-linux-gnu on 3.10 and on 4.15 kernel.
* linux: Remove aarch64 ipc_priv.hAdhemerval Zanella2020-03-051-21/+0
| | | | | The aarch64 ipc_priv.h is superflous since __ASSUME_SYSVIPC_DEFAULT_IPC_64 is now defined as default.
* Linux: Use __fstatat64 in fchmodat implementationFlorian Weimer2020-03-051-1/+1
| | | | | | | fstatat64 depends on inlining to produce the desired __fxstatat64 call, which does not happen with -Os, leading to a link failure with an undefined reference to fstatat64. __fxstatat64 has a macro definition in include/sys/stat.h and thus avoids the problem.
* Linux: Use AT_FDCWD in utime, utimes when calling utimensatFlorian Weimer2020-03-052-2/+4
| | | | | | 0 is a valid descriptor without any special meaning. Reviewed-by: Lukasz Majewski <lukma@denx.de>
* y2038: linux: Provide __utime64 implementationLukasz Majewski2020-03-032-1/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces auto generated wrapper (as described in sysdeps/unix/sysv/linux/syscalls.list) for utime with one which adds extra support for setting file's access and modification 64 bit time on machines with __TIMESIZE != 64. Internally, the __utimensat_time64 helper function is used. This patch is necessary for having architectures with __WORDSIZE == 32 && __TIMESIZE != 64 Y2038 safe. Moreover, a 32 bit version - __utime has been refactored to internally use __utime64. The __utime is now supposed to be used on systems still supporting 32 bit time (__TIMESIZE != 64) - hence the necessary conversion between struct utimbuf and struct __utimbuf64. Build tests: ./src/scripts/build-many-glibcs.py glibcs Run-time tests: - Run specific tests on ARM/x86 32bit systems (qemu): https://github.com/lmajewski/meta-y2038 and run tests: https://github.com/lmajewski/y2038-tests/commits/master Above tests were performed with Y2038 redirection applied as well as without to test proper usage of both __utime64 and __utime. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* y2038: linux: Provide __utimes64 implementationLukasz Majewski2020-03-031-11/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides new __utimes64 explicit 64 bit function for setting file's 64 bit attributes for access and modification time. Internally, the __utimensat64_helper function is used. This patch is necessary for having architectures with __WORDSIZE == 32 Y2038 safe. Moreover, a 32 bit version - __utimes has been refactored to internally use __utimes64. The __utimes is now supposed to be used on systems still supporting 32 bit time (__TIMESIZE != 64) - hence the necessary conversion of struct timeval to 64 bit struct __timeval64. Build tests: ./src/scripts/build-many-glibcs.py glibcs Run-time tests: - Run specific tests on ARM/x86 32bit systems (qemu): https://github.com/lmajewski/meta-y2038 and run tests: https://github.com/lmajewski/y2038-tests/commits/master Above tests were performed with Y2038 redirection applied as well as without to test proper usage of both __utimes64 and __utimes. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* microblaze: vfork is always availableFlorian Weimer2020-03-031-4/+0
| | | | | | | | | | Due to the built-in tables, __NR_vfork is always defined, so the fork-based fallback code is never used. (It appears that the vfork system call was wired up when the port was contributed to the kernel.) Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* m68k: getpagesize syscall number is always availableFlorian Weimer2020-03-031-4/+0
| | | | | | Due to the built-in tables, __NR_getpagesize is always defined. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Linux: epoll_pwait syscall number is always availableFlorian Weimer2020-03-031-16/+0
| | | | | | Due to the built-in tables, __NR_epoll_pwait is always defined. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* x86_64: Do not define __NR_semtimedop in <sysdep.h>Florian Weimer2020-03-031-7/+0
| | | | | | The definition is always available from the built-in system call table. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* ia64: Do not define __NR_semtimedop in <sysdep.h>Florian Weimer2020-03-031-6/+0
| | | | | | The definition is always available from the built-in system call table. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Linux: open_by_handle_at syscall number is always availableFlorian Weimer2020-03-031-9/+0
| | | | | | Due to the built-in tables, __NR_open_by_handle_at is always defined. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Linux: pciconfig_iobase syscall number is always available on alphaFlorian Weimer2020-03-031-2/+0
| | | | | | Due to the built-in tables, __NR_pciconfig_iobase is always defined. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-10-31 20:44:20 +0000