about summary refs log tree commit diff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
...
* oldmalloc: preserve errno across freeRich Felker2021-01-301-0/+4
| | | | | | | | as an outcome of Austin Group issue #385, future versions of the standard will require free not to alter the value of errno. save and restore it individually around the calls to madvise and munmap so that the cost is not imposed on calls to free that do not result in any syscall.
* fix build regression in oldmallocRich Felker2021-01-301-1/+1
| | | | | | commit 8d37958d58cf36f53d5fcc7a8aa6d633da6071b2 inadvertently broke oldmalloc by having it implement __libc_malloc rather than __libc_malloc_impl.
* preserve errno across freeRich Felker2021-01-301-2/+10
| | | | | | | | as an outcome of Austin Group issue #385, future versions of the standard will require free not to alter the value of errno. save and restore it individually around the calls to madvise and munmap so that the cost is not imposed on calls to free that do not result in any syscall.
* fix inconsistent signature of __libc_start_mainRich Felker2021-01-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | commit 7586360badcae6e73f04eb1b8189ce630281c4b2 removed the unused arguments from the definition of __libc_start_main, making it incompatible with the declaration at the point of call, which still passed 6 arguments. calls with mismatched function type have undefined behavior, breaking LTO and any other tooling that checks for function signature mismatch. removing the extra arguments from the point of call (crt1) is not an option for fixing this, since that would be a change in ABI surface between application and libc. adding back the extra arguments requires some care. on archs that pass arguments on the stack or that reserve argument spill space for the callee on the stack, it imposes an ABI requirement on the caller to provide such space. the modern crt1.c entry point provides such space, but originally there was arch-specific asm for the call to __libc_start_main. the last of this asm was removed in commit 6fef8cafbd0f6f185897bc87feb1ff66e2e204e1, and manual review of the code removed and its prior history was performed to check that all archs/variants passed the legacy init/fini/ldso_fini arguments.
* fail posix_spawn file_actions operations with negative fdsRich Felker2021-01-304-0/+4
| | | | | | | | | | | these functions are specified to fail with EBADF on negative fd arguments. apart from close, they are also specified to fail if the value exceeds OPEN_MAX, but as written it is not clear that this imposes any requirement when OPEN_MAX is not defined, and it's undesirable to impose a dynamic limit (via setrlimit) here since the limit at the time of posix_spawn may be different from the limit at the time of setting up the file actions. this may require revisiting later.
* fix VIDIOC_DQEVENT (v4l2) ioctl fallback for pre-5.6 kernelsRich Felker2020-12-141-1/+9
| | | | | | | | | | | | commit 2412638bb39eb799b2600393bbd71cca8ae96bb2 got the size of struct v4l2_event wrong and failed to account for the fact that the old struct might be either 120 bytes with time misaligned mod 8, or 128 bytes with time aligned mod 8, due to the contained union having 64-bit members whose alignment is arch-dependent. rather than adding new logic to handle the differences, use an actual stripped-down version of the structure in question to derive the ioctl number, size, and offsets.
* fix v4l2 buffer ioctl fallbacks for pre-5.6 kernelsArnd Bergmann2020-12-141-4/+4
| | | | | | | | commit 2412638bb39eb799b2600393bbd71cca8ae96bb2 got the size of struct v4l2_buffer wrong and omitted the tv_usec member slot from the offset list, so the ioctl numbers never matched and fallback code path was never taken. this caused the affected ioctls to fail with ENOTTY on kernels not new enough to have the native time64 ioctls.
* use libc-internal malloc for newlocale/freelocaleRich Felker2020-12-092-0/+10
| | | | | | | this is necessary for MT-fork correctness now that the code runs under locale lock. it would not be hard to avoid, but __get_locale is already using libc-internal malloc anyway. this can be reconsidered during locale overhaul later if needed.
* drop use of pthread_once in newlocaleRich Felker2020-12-091-9/+7
| | | | | | | in general, pthread_once is not compatible with MT-fork constraints (commit 167390f05564e0a4d3fcb4329377fd7743267560). here it actually no longer matters, because it's now called with a lock held, but since the lock is held it's pointless to use pthread_once.
* lift locale lock out of internal __get_localeRich Felker2020-12-094-18/+19
| | | | | | this allows the lock to be shared with setlocale, eliminates repeated per-category lock/unlock in newlocale, and will allow the use of pthread_once in newlocale to be dropped (to be done separately).
* fix misleading comment in strstrRich Felker2020-12-091-1/+1
| | | | | | | | the intent here is just to scan at least l bytes forward for the end of the haystack and at least some decent minimum to avoid doing it over and over if the needle is short, with no need to be precise. the comment erroneously stated this as an estimate for MIN when it's actually an estimate for MAX.
* drop use of pthread_once for aio thread stack size initRich Felker2020-12-081-10/+8
| | | | | | | | | | | | | pthread_once is not compatible with MT-fork constraints (commit 167390f05564e0a4d3fcb4329377fd7743267560) and is not needed here anyway; we already have a lock suitable for initialization. while changing this, fix a corner case where AT_MINSIGSTKSZ gives a value that's more than MINSIGSTKSZ but by a margin of less than 2048, thereby causing the size to be reduced. it shouldn't matter but the intent was to be the larger of a 2048-byte margin over the legacy fixed minimum stack requirement or a 512-byte margin over the minimum the kernel reports at runtime.
* fix omission of non-stub pthread_mutexattr_getprotocolRich Felker2020-12-071-1/+1
| | | | | | | this change should have been made when priority inheritance mutex support was added. if priority protection is also added at some point the implementation will need to change and will probably no longer be a simple bit shuffling.
* fix failure to preserve r6 in s390x asm; per ABI it is call-savedRich Felker2020-12-042-0/+8
| | | | | | | | | | | | | | | | | | both __clone and __syscall_cp_asm failed to restore the original value of r6 after using it as a syscall argument register. the extent of breakage is not known, and in some cases may be mitigated by the only callers being internal to libc; if they used r6 but no longer needed its value after the call, they may not have noticed the problem. however at least posix_spawn (which uses __clone) was observed returning to the application with the wrong value in r6, leading to crash. since the call frame ABI already provides a place to spill registers, fixing this is just a matter of using it. in __clone, we also spuriously restore r6 in the child, since the parent branch directly returns to the caller. this takes the value from an uninitialized slot of the child's stack, but is harmless since there is no caller to return to in the child.
* implement reallocarrayAriadne Conill2020-11-301-0/+13
| | | | | | | | reallocarray is an extension introduced by OpenBSD, which introduces calloc overflow checking to realloc. glibc 2.28 introduced support for this function behind _GNU_SOURCE, while glibc 2.29 allows its usage in _DEFAULT_SOURCE.
* implement realpath directly instead of using procfs readlinkRich Felker2020-11-301-23/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | inability to use realpath in chroot/container without procfs access and at early boot prior to mount of /proc has been an ongoing issue, and it turns out realpath was one of the last remaining interfaces that needed procfs for its core functionality. during investigation while reimplementing, it was determined that there were also serious problems with the procfs-based implementation. most seriously it was unsafe on pre-O_PATH kernels, and unlike other places where O_PATH was used, the unsafety was hard or impossible to fix because O_NOFOLLOW can't be used (since the whole purpose was to follow symlinks). the new implementation is a direct one, performing readlink on each path component to resolve it. an explicit stack, as opposed to recursion, is used to represent the remaining components to be processed. the stack starts out holding just the input string, and reading a link pushes the link contents onto the stack. unlike many other implementations, this one does not call getcwd initially for relative pathnames. instead it accumulates initial .. components to be applied to the working directory if the result is still a relative path. this avoids calling getcwd (which may fail) at all when symlink traversal will eventually yield an absolute path. it also doesn't use any form of stat operation; instead it arranges for readlink to tell it when a non-directory is used in a context where a directory is needed. this minimizes the number of syscalls needed, avoids accessing inodes when the directory table suffices, and reduces the amount of code pulled in for static linking.
* fix mallocng regression in malloc_usable_size with null argumentDominic Chen2020-11-291-0/+1
| | | | | commit d1507646975cbf6c3e511ba07b193f27f032d108 added support for null argument in oldmalloc and was overlooked when switching to mallocng.
* fix segfault in lutimes when tv argument is NULLÉrico Rolim2020-11-291-5/+7
| | | | | | | calling lutimes with tv=0 is valid if the application wants to set the timestamps to the current time. this commit makes it so the timespec struct is populated with values from tv only if tv != 0 and calls utimensat with times=0 if tv == 0.
* arm fabs and sqrt: support single-precision-only fpu variantsJinliang Li2020-11-292-2/+2
|
* work around linux bug in readlink syscall with zero buffer sizeRich Felker2020-11-232-3/+17
| | | | | | | | | | linux fails with EINVAL when a zero buffer size is passed to the syscall. this is non-conforming because POSIX already defines EINVAL with a significantly different meaning: the target is not a symlink. since the request is semantically valid, patch it up by using a dummy buffer of length one, and truncating the return value to zero if it succeeds.
* parse v3 or future-unknown zoneinfo file versions as v2+Rich Felker2020-11-221-1/+1
| | | | | | | | the v1 zoneinfo format with 32-bit time is deprecated. previously, the v2 parsing code was only used if an exact match for '2' was found in the version field of the header. this was already incorrect for v3 files (trivial differences from v2 that arguably didn't merit a new version number anyway) but also failed to be future-proof.
* explicitly prefer 64-bit/v2 zoneinfo tablesRich Felker2020-11-221-1/+1
| | | | | | | | | since commit 38143339646a4ccce8afe298c34467767c899f51, the condition sizeof(time_t) > 4 is always true, so there is no functional change being made here. but semantically, the 64-bit tables should always be preferred now, because upstream zic (zoneinfo compiler) has quietly switched to emitting empty 32-bit tables by default, and the resulting backwards-incompatible zoneinfo files will be encountered in the wild.
* fix regression in pthread_exitRich Felker2020-11-202-1/+3
| | | | | | | | | | | | | | | commit d26e0774a59bb7245b205bc8e7d8b35cc2037095 moved the detach state transition at exit before the thread list lock was taken. this inadvertently allowed pthread_join to race to take the thread list lock first, and proceed with unmapping of the exiting thread's memory. we could fix this by just revering the offending commit and instead performing __vm_wait unconditionally before taking the thread list lock, but that may be costly. instead, bring back the old DT_EXITING vs DT_EXITED state distinction that was removed in commit 8f11e6127fe93093f81a52b15bb1537edc3fc8af, and don't transition to DT_EXITED (a value of 0, which is what pthread_join waits for) until after the lock has been taken.
* rewrite wcsnrtombs to fix buffer overflow and other bugsRich Felker2020-11-191-27/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the original wcsnrtombs implementation, which has been largely untouched since 0.5.0, attempted to build input-length-limiting conversion on top of wcsrtombs, which only limits output length. as best I recall, this choice was made out of a mix of disdain over having yet another variant function to implement (added in POSIX 2008; not standard C) and preference not to switch things around and implement the wcsrtombs in terms of the more general new function, probably over namespace issues. the strategy employed was to impose output limits that would ensure the input limit wasn't exceeded, then finish up the tail character-at-a-time. unfortunately, none of that worked correctly. first, the logic in the wcsrtombs loop was wrong in that it could easily get stuck making no forward progress, by imposing an output limit too small to convert even one character. the character-at-a-time loop that followed was even worse. it made no effort to ensure that the converted multibyte character would fit in the remaining output space, only that there was a nonzero amount of output space remaining. it also employed an incorrect interpretation of wcrtomb's interface contract for converting the null character, thereby failing to act on end of input, and remaining space accounting was subject to unsigned wrap-around. together these errors allow unbounded overflow of the destination buffer, controlled by input length limit and input wchar_t string contents. given the extent to which this function was broken, it's plausible that most applications that would have been rendered exploitable were sufficiently broken not to be usable in the first place. however, it's also plausible that common (especially ASCII-only) inputs succeeded in the wcsrtombs loop, which mostly worked, while leaving the wildly erroneous code in the second loop exposed to particular non-ASCII inputs. CVE-2020-28928 has been assigned for this issue.
* protect destruction of process-shared mutexes against robust list racesRich Felker2020-11-191-1/+5
| | | | | | | | | | | | | | | after a non-normal-type process-shared mutex is unlocked, it's immediately available to another thread to lock, unlock, and destroy, but the first unlocking thread may still have a pointer to it in its robust_list pending slot. this means, on async process termination, the kernel may attempt to access and modify the memory that used to contain the mutex -- memory that may have been reused for some other purpose after the mutex was destroyed. setting up for this kind of race to occur is difficult to begin with, requiring dynamic use of shared memory maps, and actually hitting the race is very difficult even with a suitable setup. so this is mostly a theoretical fix, but in any case the cost is very low.
* pthread_exit: don't __vm_wait under thread list lockRich Felker2020-11-191-9/+15
| | | | | | | | | | | | | | | the __vm_wait operation can delay forward progress arbitrarily long if a thread holding the lock is interrupted by a signal. in a worst case this can deadlock. any critical section holding the thread list lock must respect lock ordering contracts and must not take any lock which is not AS-safe. to fix, move the determination of thread joinable/detached state to take place before the killlock and thread list lock are taken. this requires reverting the atomic state transition if we determine that the exiting thread is the last thread and must call exit, but that's easy to do since it's a single-threaded context with application signals blocked.
* lift child restrictions after multi-threaded forkRich Felker2020-11-1116-4/+151
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | as the outcome of Austin Group tracker issue #62, future editions of POSIX have dropped the requirement that fork be AS-safe. this allows but does not require implementations to synchronize fork with internal locks and give forked children of multithreaded parents a partly or fully unrestricted execution environment where they can continue to use the standard library (per POSIX, they can only portably use AS-safe functions). up until recently, taking this allowance did not seem desirable. however, commit 8ed2bd8bfcb4ea6448afb55a941f4b5b2b0398c0 exposed the extent to which applications and libraries are depending on the ability to use malloc and other non-AS-safe interfaces in MT-forked children, by converting latent very-low-probability catastrophic state corruption into predictable deadlock. dealing with the fallout has been a huge burden for users/distros. while it looks like most of the non-portable usage in applications could be fixed given sufficient effort, at least some of it seems to occur in language runtimes which are exposing the ability to run unrestricted code in the child as part of the contract with the programmer. any attempt at fixing such contracts is not just a technical problem but a social one, and is probably not tractable. this patch extends the fork function to take locks for all libc singletons in the parent, and release or reset those locks in the child, so that when the underlying fork operation takes place, the state protected by these locks is consistent and ready for the child to use. locking is skipped in the case where the parent is single-threaded so as not to interfere with legacy AS-safety property of fork in single-threaded programs. lock order is mostly arbitrary, but the malloc locks (including bump allocator in case it's used) must be taken after the locks on any subsystems that might use malloc, and non-AS-safe locks cannot be taken while the thread list lock is held, imposing a requirement that it be taken last.
* convert malloc use under libc-internal locks to use internal allocatorRich Felker2020-11-117-0/+36
| | | | | | | | | | | | | this change lifts undocumented restrictions on calls by replacement mallocs to libc functions that might take these locks, and sets the stage for lifting restrictions on the child execution environment after multithreaded fork. care is taken to #define macros to replace all four functions (malloc, calloc, realloc, free) even if not all of them will be used, using an undefined symbol name for the ones intended not to be used so that any inadvertent future use will be caught at compile time rather than directed to the wrong implementation.
* give libc access to its own malloc even if public malloc is interposedRich Felker2020-11-117-1/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | allowing the application to replace malloc (since commit c9f415d7ea2dace5bf77f6518b6afc36bb7a5732) has brought multiple headaches where it's used from various critical sections in libc components. for example: - the thread-local message buffers allocated for dlerror can't be freed at thread exit time because application code would then run in the context of a non-existant thread. this was handled in commit aa5a9d15e09851f7b4a1668e9dbde0f6234abada by queuing them for free later. - the dynamic linker has to be careful not to pass memory allocated at early startup time (necessarily using its own malloc) to realloc or free after redoing relocations with the application and all libraries present. bugs in this area were fixed several times, at least in commits 0c5c8f5da6e36fe4ab704bee0cd981837859e23f and 2f1f51ae7b2d78247568e7fdb8462f3c19e469a4 and possibly others. - by calling the allocator from contexts where libc-internal locks are held, we impose undocumented requirements on alternate malloc implementations not to call into any libc function that might attempt to take these locks; if they do, deadlock results. - work to make fork of a multithreaded parent give the child an unrestricted execution environment is blocked by lock order issues as long as the application-provided allocator can be called with libc-internal locks held. these problems are all fixed by giving libc internals access to the original, non-replaced allocator, for use where needed. it can't be used everywhere, as some interfaces like str[n]dup, open_[w]memstream, getline/getdelim, etc. are required to provide the called memory obtained as if by (the public) malloc. and there are a number of libc interfaces that are "pure library" code, not part of some internal singleton, and where using the application's choice of malloc implementation is preferable -- things like glob, regex, etc. one might expect there to be significant cost to static-linked programs, pulling in two malloc implementations, one of them mostly-unused, if malloc is replaced. however, in almost all of the places where malloc is used internally, care has been taken already not to pull in realloc/free (i.e. to link with just the bump allocator). this size optimization carries over automatically. the newly-exposed internal allocator functions are obtained by renaming the actual definitions, then adding new wrappers around them with the public names. technically __libc_realloc and __libc_free could be aliases rather than needing a layer of wrapper, but this would almost surely break certain instrumentation (valgrind) and the size and performance difference is negligible. __libc_calloc needs to be handled specially since calloc is designed to work with either the internal or the replaced malloc. as a bonus, this change also eliminates the longstanding ugly dependency of the static bump allocator on order of object files in libc.a, by making it so there's only one definition of the malloc function and having it in the same source file as the bump allocator.
* dlerror: don't gratuitously hold freebuf_queue lock while freeingRich Felker2020-11-111-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | thread-local buffers allocated for dlerror need to be queued for free at a later time when the owning thread exits, since malloc may be replaced by application code and the exiting context is not valid to call application code from. the code to process queue of pending frees, introduced in commit aa5a9d15e09851f7b4a1668e9dbde0f6234abada, gratuitously held the lock for the entire duration of queue processing, updating the global queue pointer after each free, despite there being no logical requirement that all frees finish before another thread can access the queue. instead, immediately claim the whole queue for freeing and release the lock, then walk the list and perform frees without the lock held. the change is unlikely to make any meaningful difference to performance, but it eliminates one point where the allocator is called under an internal lock. since the allocator may be application-provided, such calls are undesirable because they allow application code to impede forward progress of libc functions in other threads arbitrarily long, and to induce deadlock if it calls a libc function that requires the same lock. the change also eliminates a lock ordering consideration that's an impediment upcoming work with multithreaded fork.
* fix erroneous pthread_cond_wait mutex waiter count logic due to typoRich Felker2020-10-301-1/+1
| | | | introduced in commit 27b2fc9d6db956359727a66c262f1e69995660aa.
* fix missing-wake regression in pthread_cond_waitRich Felker2020-10-301-0/+5
| | | | | | | | | | | | | | | the reasoning in commit 2d0bbe6c788938d1332609c014eeebc1dff966ac was not entirely correct. while it's true that setting the waiters flag ensures that the next unlock will perform a wake, it's possible that the wake is consumed by a mutex waiter that has no relationship with the condvar wait queue being processed, which then takes the mutex. when that thread subsequently unlocks, it sees no waiters, and leaves the rest of the condvar queue stuck. bring back the waiter count adjustment, but skip it for PI mutexes, for which a successful lock-after-waiting always sets the waiters bit. if future changes are made to bring this same waiters-bit contract to all lock types, this can be reverted.
* add support for SIGEV_THREAD_ID timersJames Y Knight2020-10-281-2/+6
| | | | | This is like SIGEV_SIGNAL, but targeted to a particular thread's tid, rather than the process.
* fix sem_close unmapping of still-referenced semaphoreRich Felker2020-10-281-3/+5
| | | | | | | | | | | | | sem_open is required to return the same sem_t pointer for all references to the same named semaphore when it's opened more than once in the same process. thus we keep a table of all the mapped semaphores and their reference counts. the code path for sem_close checked the reference count, but then proceeded to unmap the semaphore regardless of whether the count had reached zero. add an immediate unlock-and-return for the nonzero refcnt case so the property of performing the munmap syscall after releasing the lock can be preserved.
* refactor setxid return path to use __syscall_retRich Felker2020-10-271-14/+9
| | | | | this avoids some spurious negation and duplicated errno logic, and brings the code in line with the newly-added multithreaded setgroups.
* fix setgroups behavior in multithreaded processRich Felker2020-10-271-1/+29
| | | | | | this function is outside the scope of the standards, but logically should behave like the set*id functions whose effects are process-global.
* avoid __synccall for setrlimit on kernels with prlimit syscallRich Felker2020-10-271-20/+17
| | | | | | resource limits have been process-wide since linux 2.6.10, and the prlimit syscall was added in 2.6.36, so prlimit can be assumed to set the resource limits correctly for the whole process.
* fix reintroduction of errno clobbering by atfork handlersRich Felker2020-10-261-0/+3
| | | | | | | | | | commit bd153422f28634bb6e53f13f80beb8289d405267 reintroduced the bug fixed in c21051e90cd27a0b26be0ac66950b7396a156ba1 by refactoring the __syscall_ret into _Fork where it once again runs before the atfork handlers are called. since _Fork is a public interface that sets errno, this can't be fixed the way it was fixed last time without making new internal interfaces. instead, just save errno, and restore it only on error to ensure that a value of 0 is never restored.
* fix pthread_cond_wait paired with with priority-inheritance mutexRich Felker2020-10-261-6/+5
| | | | | | | | | | | | | | | | | | | | | pthread_cond_wait arranged for requeued waiters to wake when the mutex is unlocked by temporarily adjusting the mutex's waiter count. commit 54ca677983d47529bab8752315ac1a2b49888870 broke this when introducing PI mutexes by repurposing the waiter count field of the mutex structure. since then, for PI mutexes, the waiter count adjustment was misinterpreted by the mutex locking code as indicating that the mutex is non a non-recoverable state. it would be possible to special-case PI mutexes here, but instead just drop all adjustment of the waiters count, and instead use the lock word waiters bit for all mutex types. since the mutex is either held by the caller or in unrecoverable state at the time the bit is set, it will necessarily still be set at the time of any subsequent valid unlock operation, and this will produce the desired effect of waking the next waiter. if waiter counts are entirely dropped at some point in the future this code should still work without modification.
* lift sigaction abort locking to fix posix_spawn child deadlockRich Felker2020-10-241-13/+16
| | | | | | | | | | | | | | | | | | commit 25ea9f712c30c32957de493d4711ee39d0bbb024 introduced a deadlock to the posix_spawn child whereby, if abort was called in the parent and ended up taking the abort lock to terminate the process, the __libc_sigaction calls in the child would wait forever to obtain a lock that would not be released. this could be fixed by having abort set the abort lock as the exit futex address, but it's cleaner to just remove the SIGABRT special handling from the internal __libc_sigaction and lift it to the public sigaction function. nothing but the posix_spawn child calls __libc_sigaction on SIGABRT, and since commit b7bc966522d73e1dc420b5ee6fc7a2e78099a08c the abort lock is held at the time of __clone, which precludes the child inheriting a kernel-level signal disposition inconsistent with the disposition on the abstract machine. this means it's fine to inspect and modify the disposition in the child without a lock.
* update crypt_blowfish to support $2b$ prefixJulien Ramseier2020-10-181-15/+23
| | | | | | | Merge changes from Solar Designer's crypt_blowfish v1.3. This makes crypt_blowfish fully compatible with OpenBSD's bcrypt by adding support for the $2b$ prefix (which behaves the same as crypt_blowfish's $2y$).
* remove unused weak definition of __tl_sync in membarrier.cRich Felker2020-10-141-5/+0
|
* move aio implementation details to a proper internal headerRich Felker2020-10-148-4/+14
| | | | | also fix the lack of declaration (and thus hidden visibility) in __stdio_close's use of __aio_close.
* remove long-unused struct __timer from pthread_impl.hRich Felker2020-10-141-5/+0
| | | | | commit 3990c5c6a40440cdb14746ac080d0ecf8d5d6733 removed the last reference.
* drop use of pthread_once in timer_createRich Felker2020-10-141-10/+7
| | | | | | | | this makes the code slightly smaller and eliminates timer_create from relevance to possible future changes to multithreaded fork. the barrier of a_store isn't technically needed here, but a_store is used anyway for internal consistency of the memory model.
* remove unused SIGTIMER handler in timer_createRich Felker2020-10-141-6/+1
| | | | | | | | | | | this was leftover from when the actual SIGEV_THREAD timer logic was in the signal handler. commit 5b74eed3b301e2227385f3bf26d3bb7c2d822cf8 replaced that with use of sigwaitinfo, with the actual signal left blocked, so the no-op signal handler was no longer serving any purpose. the signal disposition reset to SIG_DFL is still needed, however, in case we inherited SIG_IGN from a foreign-libc process.
* remove incorrect fflush from assert failure handlerRich Felker2020-10-141-1/+0
| | | | | | | assert is not specified to flush open stdio streams, and doing so can block indefinitely waiting for a lock already held or an output operation to a file that can't accept more output until an unsatisfiable condition is met.
* fix getgrouplist when nscd reports an empty listRich Felker2020-10-141-1/+2
| | | | | | | commit 500c6886c654fd45e4926990fee2c61d816be197 broke this by fixing the behavior of fread to conform to the C standard; getgroupslist was assuming the old behavior, that a request to read 1 member of length 0 would return 1, not 0.
* fix posix_spawn interaction with fork and abort by taking lockRich Felker2020-10-141-3/+13
| | | | | | | | | | | | | this change prevents the child created concurrently with abort from seeing the SIGABRT disposition change from SIG_IGN to SIG_DFL (other changes are not visible anyway) and prevents leaking the write end of the child pipe to children created by fork in another thread, which may block return of posix_spawn indefinitely if the forked child does not exit or exec. along with other changes, this suggests that __abort_lock should perhaps eventually be renamed to reflect that it's becoming a broader lock on related "process lifetime" state.
* fix unintended observability of SIGABRT disposition reset via sigactionRich Felker2020-10-141-9/+8
| | | | | | | | | | | the existing abort locking logic in sigaction only accounted for attempts to change the disposition, not attempts to observe the change made by abort. unfortunately the change is still observable in at least one other place: inheritance of signal dispositions across exec and posix_spawn. fixing these is a separate task and it's not even clear whether a complete fix is possible.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-11 12:12:01 +0000