aboutsummaryrefslogtreecommitdiff
path: root/src/select
AgeCommit message (Collapse)AuthorFilesLines
2024-01-21expose ppoll in default feature profileRich Felker1-1/+1
the ppoll function has been accepted as a future part of the standard as the outcome of Austin Group tracker issue 1263. at some point it should be exposed unconditionally, but for now, expose it in the default feature profile.
2024-01-21move ppoll from src/linux to src/select reflecting future standardizationRich Felker1-0/+26
the ppoll function has been accepted as a future part of the standard as the outcome of Austin Group tracker issue 1263. move the source file to reflect this.
2023-03-03poll: fix misuse of timespec type on 32-bit archs without poll syscallRich Felker1-2/+7
this function was overlooked during the time64 transition, probably as a result of not having any time-related types in its application-side interface. however, for archs that lack the traditional poll syscall and have only ppoll, it used timespec as part of its interface with the kernel: the millisecond timeout was converted to a timespec to pass to SYS_ppoll. this is a type/ABI mismatch on 32-bit archs with legacy time32 syscalls. only one supported arch, or1k, is affected. all of the others either have SYS_poll, or are 64-bit. rather than using timespec, define a type locally to match what the kernel expects. the condition (SYS_ppoll_time64 == SYS_ppoll), comparable to conditions used elsewhere in timespec-handling code, evaluates true for "natively time64" 32-bit archs including x32, future riscv32, and all future 32-bit archs (via definitions in internal syscall.h). otherwise, the arch is either 64-bit or has syscalls that take the legacy type, and in either case "long" is correct. this fix is based on bug report and proposal by Alexey Izbyshev but with a different approach to the changes to minimize the contextual knowledge needed for a reader to understand the source file.
2023-03-02select: fix 64-bit timeout truncation on pre-time64 kernelsAlexey Izbyshev1-0/+1
If the (normalized) timeout passed to select exceeds INT_MAX seconds on an arch with SYS_pselect6_time64 and the kernel is too old to support time64 syscalls, the timeout is implicitly converted to (32-bit) long on the fallback path, losing its upper 32 bits and potentially becoming a small positive value, violating the intended semantics, or even a negative value, causing the fallback syscall failure. Fix this by saturating the timeout at INT_MAX as done in other time64 fallback cases.
2019-08-07fix regression in select with no timeoutRich Felker1-1/+2
commit 722a1ae3351a03ab25010dbebd492eced664853b inadvertently passed a copy of {s,us} to the syscall even if the timeout argument tv was null, thereby causing immediate timeout (polling) in place of unlimited timeout. only archs using SYS_select were affected.
2019-07-30select: overhaul for time64Rich Felker1-13/+31
major changes are made alongside adding time64 syscall support to account for issues found during research. select historically accepts non-normalized (tv_usec not restricted to less than 1000000) timeouts, and the kernel normalizes them, but the normalization code is buggy and subject to integer overflows. since normalization is needed anyway when using SYS_pselect6 or SYS_pselect6_time64 as the backend, simply do it up-front to eliminate both code path complexity and the possibility of kernel bugs. as a side effect, select no longer updates the caller's timeout timeval with the remaining time. previously, archs that used SYS_select updated it and archs that used SYS_pselect6 didn't. this change may turn out to be controversial and may need revisiting, but in any case the old behavior was not strictly conforming. POSIX allows modification of the timeout "upon successful completion", but the Linux syscall modifies it upon unsuccessful completion (EINTR) as well (and presumably each time the syscall stops and restarts before it's known whether completion will be successful). it's possible that this language does not reflect the actual intent of the standard, since other historical implementations probably behaved like Linux, but that should be clarified if there's a desire to bring the old behavior back. regardless, programs that are depending on this are not correct and are already broken on some archs we support.
2019-07-28pselect, ppoll: add time64 syscall support, decouple 32-bit time_tRich Felker1-3/+17
time64 syscall is used only if it's the only one defined for the arch, or if the requested timeout length does not fit in 32 bits. on current 32-bit archs where time_t is a 32-bit type, this makes it statically unreachable. on 64-bit archs, there are only superficial changes to the code after preprocessing. both before and after these changes, these functions copied their timeout arguments to avoid letting the kernel clobber the caller's copies. now, the copying also serves to change the type from userspace timespec to a pair of longs, which makes a difference only in the 32-bit fallback case, not on 64-bit.
2018-09-12reduce spurious inclusion of libc.hRich Felker3-3/+0
libc.h was intended to be a header for access to global libc state and related interfaces, but ended up included all over the place because it was the way to get the weak_alias macro. most of the inclusions removed here are places where weak_alias was needed. a few were recently introduced for hidden. some go all the way back to when libc.h defined CANCELPT_BEGIN and _END, and all (wrongly implemented) cancellation points had to include it. remaining spurious users are mostly callers of the LOCK/UNLOCK macros and files that use the LFS64 macro to define the awful *64 aliases. in a few places, new inclusion of libc.h is added because several internal headers no longer implicitly include libc.h. declarations for __lockfile and __unlockfile are moved from libc.h to stdio_impl.h so that the latter does not need libc.h. putting them in libc.h made no sense at all, since the macros in stdio_impl.h are needed to use them correctly anyway.
2014-05-29support linux kernel apis (new archs) with old syscalls removedRich Felker2-0/+26
such archs are expected to omit definitions of the SYS_* macros for syscalls their kernels lack from arch/$ARCH/bits/syscall.h. the preprocessor is then able to select the an appropriate implementation for affected functions. two basic strategies are used on a case-by-case basis: where the old syscalls correspond to deprecated library-level functions, the deprecated functions have been converted to wrappers for the modern function, and the modern function has fallback code (omitted at the preprocessor level on new archs) to make use of the old syscalls if the new syscall fails with ENOSYS. this also improves functionality on older kernels and eliminates the incentive to program with deprecated library-level functions for the sake of compatibility with older kernels. in other situations where the old syscalls correspond to library-level functions which are not deprecated but merely lack some new features, such as the *at functions, the old syscalls are still used on archs which support them. this may change at some point in the future if or when fallback code is added to the new functions to make them usable (possibly with reduced functionality) on old kernels.
2014-05-26fix type of extended argument array to pselect6 syscallRich Felker1-1/+2
this only matters on x32 (and perhaps future 32-on-64 abis for other archs); otherwise the type is long anyway. the cast through uintptr_t prevents nonsensical "sign extension" of pointers, and follows the principle that uintptr_t is the canonical integer type to which pointer conversion is safe.
2013-03-26remove __SYSCALL_SSLEN arch macro in favor of using public _NSIGRich Felker1-1/+2
the issue at hand is that many syscalls require as an argument the kernel-ABI size of sigset_t, intended to allow the kernel to switch to a larger sigset_t in the future. previously, each arch was defining this size in syscall_arch.h, which was redundant with the definition of _NSIG in bits/signal.h. as it's used in some not-quite-portable application code as well, _NSIG is much more likely to be recognized and understood immediately by someone reading the code, and it's also shorter and less cluttered. note that _NSIG is actually 65/129, not 64/128, but the division takes care of throwing away the off-by-one part.
2012-09-06use restrict everywhere it's required by c99 and/or posix 2008Rich Felker2-2/+2
to deal with the fact that the public headers may be used with pre-c99 compilers, __restrict is used in place of restrict, and defined appropriately for any supported compiler. we also avoid the form [restrict] since older versions of gcc rejected it due to a bug in the original c99 standard, and instead use the form *restrict.
2012-08-09fix (hopefully) all hard-coded 8's for kernel sigset_t sizeRich Felker1-1/+1
some minor changes to how hard-coded sets for thread-related purposes are handled were also needed, since the old object sizes were not necessarily sufficient. things have gotten a bit ugly in this area, and i think a cleanup is in order at some point, but for now the goal is just to get the code working on all supported archs including mips, which was badly broken by linux rejecting syscalls with the wrong sigset_t size.
2011-04-17overhaul pthread cancellationRich Felker3-17/+3
this patch improves the correctness, simplicity, and size of cancellation-related code. modulo any small errors, it should now be completely conformant, safe, and resource-leak free. the notion of entering and exiting cancellation-point context has been completely eliminated and replaced with alternative syscall assembly code for cancellable syscalls. the assembly is responsible for setting up execution context information (stack pointer and address of the syscall instruction) which the cancellation signal handler can use to determine whether the interrupted code was in a cancellable state. these changes eliminate race conditions in the previous generation of cancellation handling code (whereby a cancellation request received just prior to the syscall would not be processed, leaving the syscall to block, potentially indefinitely), and remedy an issue where non-cancellable syscalls made from signal handlers became cancellable if the signal handler interrupted a cancellation point. x86_64 asm is untested and may need a second try to get it right.
2011-03-24overhaul cancellation to fix resource leaks and dangerous behavior with signalsRich Felker2-0/+2
this commit addresses two issues: 1. a race condition, whereby a cancellation request occurring after a syscall returned from kernelspace but before the subsequent CANCELPT_END would cause cancellable resource-allocating syscalls (like open) to leak resources. 2. signal handlers invoked while the thread was blocked at a cancellation point behaved as if asynchronous cancellation mode wer in effect, resulting in potentially dangerous state corruption if a cancellation request occurs. the glibc/nptl implementation of threads shares both of these issues. with this commit, both are fixed. however, cancellation points encountered in a signal handler will not be acted upon if the signal was received while the thread was already at a cancellation point. they will of course be acted upon after the signal handler returns, so in real-world usage where signal handlers quickly return, it should not be a problem. it's possible to solve this problem too by having sigaction() wrap all signal handlers with a function that uses a pthread_cleanup handler to catch cancellation, patch up the saved context, and return into the cancellable function that will catch and act upon the cancellation. however that would be a lot of complexity for minimal if any benefit...
2011-03-20global cleanup to use the new syscall interfaceRich Felker3-3/+3
2011-02-15yet another ugly legacy syscall rename...Rich Felker1-1/+1
2011-02-12initial check-in, version 0.5.0v0.5.0Rich Felker3-0/+39