about summary refs log tree commit diff
path: root/src/select
Commit message (Collapse)AuthorAgeFilesLines
* fix regression in select with no timeoutRich Felker2019-08-071-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.
* select: overhaul for time64Rich Felker2019-07-301-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.
* pselect, ppoll: add time64 syscall support, decouple 32-bit time_tRich Felker2019-07-281-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.
* reduce spurious inclusion of libc.hRich Felker2018-09-123-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.
* support linux kernel apis (new archs) with old syscalls removedRich Felker2014-05-292-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.
* fix type of extended argument array to pselect6 syscallRich Felker2014-05-261-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.
* remove __SYSCALL_SSLEN arch macro in favor of using public _NSIGRich Felker2013-03-261-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.
* use restrict everywhere it's required by c99 and/or posix 2008Rich Felker2012-09-062-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.
* fix (hopefully) all hard-coded 8's for kernel sigset_t sizeRich Felker2012-08-091-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.
* overhaul pthread cancellationRich Felker2011-04-173-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.
* overhaul cancellation to fix resource leaks and dangerous behavior with signalsRich Felker2011-03-242-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...
* global cleanup to use the new syscall interfaceRich Felker2011-03-203-3/+3
|
* yet another ugly legacy syscall rename...Rich Felker2011-02-151-1/+1
|
* initial check-in, version 0.5.0 v0.5.0Rich Felker2011-02-123-0/+39