mirror of
https://sourceware.org/git/glibc.git
synced 2024-11-22 04:50:07 +00:00
sysvipc: Fix semtimedop for Linux < 5.1 for 64-bit ABI
Both powerpc64 and s390x provides semtimedop through __NR_ipc for pre v5.1 kernel. Neither the y2038 support (7c437d3778
) nor the attempt to fix an issue for !__ASSUME_DIRECT_SYSVIPC_SYSCALLS (aaa12e9ff0
) took this in consideration. This patch fixes it by issuing __NR_semtimedop_time64 iff it is defined, otherwise __NR_semtimeop is issued if both __ASSUME_DIRECT_SYSVIPC_SYSCALLS it set and __NR_semtimedop is define, other __NR_ipc is used instead. To summarize: 1. For 32-bit architetures __NR_semtimedop_time64 is always issued. The fallback is used only for !__ASSUME_TIME64_SYSCALLS and it issues either __NR_ipc or __NR_semtimedop. 2. For 64-bit architecture with wire-up SysV syscall (__ASSUME_DIRECT_SYSVIPC_SYSCALLS and __NR_semtimeop defined) __NR_semtimeop is issued. 3. Otherwise __NR_ipc is used instead. Checked on x86_64-linux-gnu, i686-linux-gnu (kernel 4.15 and 5.4), powerpc64le (kernel 4.18), and s390x (kernel 4.12). Reviewed-by: Matheus Castanho <msc@linux.ibm.com>
This commit is contained in:
parent
e75fbaaa21
commit
2deb779390
@ -26,11 +26,15 @@ int
|
||||
__semtimedop64 (int semid, struct sembuf *sops, size_t nsops,
|
||||
const struct __timespec64 *timeout)
|
||||
{
|
||||
#ifndef __NR_semtimedop_time64
|
||||
# define __NR_semtimedop_time64 __NR_semtimedop
|
||||
int r;
|
||||
#if defined __NR_semtimedop_time64
|
||||
r = INLINE_SYSCALL_CALL (semtimedop_time64, semid, sops, nsops, timeout);
|
||||
#elif defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS && defined __NR_semtimedop
|
||||
r = INLINE_SYSCALL_CALL (semtimedop, semid, sops, nsops, timeout);
|
||||
#else
|
||||
r = INLINE_SYSCALL_CALL (ipc, IPCOP_semtimedop, semid,
|
||||
SEMTIMEDOP_IPC_ARGS (nsops, sops, timeout));
|
||||
#endif
|
||||
int r = INLINE_SYSCALL_CALL (semtimedop_time64, semid, sops, nsops,
|
||||
timeout);
|
||||
|
||||
#ifndef __ASSUME_TIME64_SYSCALLS
|
||||
if (r == 0 || errno != ENOSYS)
|
||||
|
Loading…
Reference in New Issue
Block a user