path: root/src
AgeCommit message (Collapse)AuthorLines
2019-04-09in membarrier fallback, allow for possibility that sigaction failsRich Felker-8/+9
this is a workaround to avoid a crashing regression on qemu-user when dynamic TLS is installed at dlopen time. the sigaction syscall should not be able to fail, but it does fail for implementation-internal signals under qemu user-level emulation if the host libc qemu is running under reserves the same signals for implementation-internal use, since qemu makes no provision to redirect/emulate them. after sigaction fails, the subsequent tkill would terminate the process abnormally as the default action. no provision to account for membarrier failing is made in the dynamic linker code that installs new TLS. at the formal level, the missing barrier in this case is incorrect, and perhaps we should fail the dlopen operation, but in practice all the archs we support (and probably all real-world archs except alpha, which isn't yet supported) should give the right behavior with no barrier at all as a consequence of consume-order properties. in the long term, this workaround should be supplemented or replaced by something better -- a different fallback approach to ensuring memory consistency, or dynamic allocation of implementation-internal signals. the latter is appealing in that it would allow cancellation to work under qemu-user too, and would even allow many levels of nested emulation.
2019-04-03fix unintended global symbols in atanl.cDan Gohman-3/+3
Mark atanhi, atanlo, and aT in atanl.c as static, as they're not intended to be part of the public API. These are already static in the LDBL_MANT_DIG == 64 code, so this patch is just making the LDBL_MANT_DIG == 113 code do the same thing.
2019-04-02use __strchrnul instead of strchr and strlen in execvpeFrediano Ziglio-2/+1
The result is the same but takes less code. Note that __execvpe calls getenv which calls __strchrnul so even using static output the size of the executable won't grow.
2019-04-01fix harmless-by-chance typo in priority inheritance mutex codeRich Felker-1/+1
commit 54ca677983d47529bab8752315ac1a2b49888870 inadvertently introduced bitwise and where logical and was intended. since the right-hand operand is always 0 or -1 whenever the left-hand operand is nonzero, the behavior happened to be equivalent.
2019-03-31implement priority inheritance mutexesRich Felker-8/+93
priority inheritance is a feature to mitigate priority inversion situations, where a execution of a medium-priority thread can unboundedly block forward progress of a high-priority thread when a lock it needs is held by a low-priority thread. the natural way to do priority inheritance would be with a simple futex flag to donate the calling thread's priority to a target thread while it waits on the futex. unfortunately, linux does not offer such an interface, but instead insists on implementing the whole locking protocol in kernelspace with special futex commands that exist solely for the purpose of doing PI mutexes. this would require the entire "trylock" logic to be duplicated in the timedlock code path for PI mutexes, since, once the previous lock holder releases the lock and the futex call returns, the lock is already held by the caller. obviously such code duplication is undesirable. instead, I've made the PI timedlock success path set the mutex lock count to -1, which can be thought of as "not yet complete", since a lock count of 0 is "locked, with no recursive references". a simple branch in a non-hot path of pthread_mutex_trylock can then see and act on this state, skipping past the code that would check and take the lock to the same code path that runs after the lock is obtained for a non-PI mutex. because we're forced to let the kernel perform the actual lock and unlock operations whenever the mutex is contended, we have to patch things up when it does the wrong thing: 1. the lock operation is not aware of whether the mutex is error-checking, so it will always fail with EDEADLK rather than deadlocking. 2. the lock operation is not aware of whether the mutex is robust, so it will successfully obtain mutexes in the owner-died state even if they're non-robust, whereas this operation should deadlock. 3. the unlock operation always sets the lock value to zero, whereas for robust mutexes, we want to set it to a special value indicating that the mutex obtained after its owner died was unlocked without marking it consistent, so that future operations all fail with ENOTRECOVERABLE. the first of these is easy to solve, just by performing a futex wait on a dummy futex address to simulate deadlock or ETIMEDOUT as appropriate. but problems 2 and 3 interact in a nasty way. to solve problem 2, we need to back out the spurious success. but if waiters are present -- which we can't just ignore, because even if we don't want to wake them, the calling thread is incorrectly inheriting their priorities -- this requires using the kernel's unlock operation, which will zero the lock value, thereby losing the "owner died with lock held" state. to solve these problems, we overload the mutex's waiters field, which is unused for PI mutexes since they don't call the normal futex wait functions, as an indicator that the PI mutex is permanently non-lockable. originally I wanted to use the count field, but there is one code path that needs to access this flag without synchronization: trylock's CAS failure path needs to be able to decide whether to fail with EBUSY or ENOTRECOVERABLE, the waiters field is already treated as a relaxed-order atomic in our memory model, so this works out nicely.
2019-03-29clean up access to mutex type in pthread_mutex_trylockRich Felker-2/+2
there was no point in masking off the pshared bit when first loading the type, since every subsequent access involves a mask anyway. not masking it may avoid a subsequent load to check the pshared flag, and it's just simpler.
2019-03-21support archs with no renameat syscall, only renameat2Drew DeVault-2/+8
2019-03-21support archs with no mlock syscall, only mlock2Drew DeVault-0/+4
2019-03-21fix data race choosing next key slot in pthread_key_createRich Felker-1/+1
commit 84d061d5a31c9c773e29e1e2b1ffe8cb9557bc58 wrongly moved the access to the global next_key outside of the scope of the lock. the error manifested as spurious failure to find an available key slot under concurrent calls to pthread_key_create, since the stopping condition could be met after only a small number of slots were examined.
2019-03-14fix crash/out-of-bound read in sscanfRich Felker-2/+3
commit d6c855caa88ddb1ab6e24e23a14b1e7baf4ba9c7 caused this "regression", though the behavior was undefined before, overlooking that f->shend=0 was being used as a sentinel for "EOF" status (actual EOF or hitting the scanf field width) of the stream helper (shgetc) functions. obviously the shgetc macro could be adjusted to check for a null pointer in addition to the != comparison, but it's the hot path, and adding extra code/branches to it begins to defeat the purpose. so instead of setting shend to a null pointer to block further reads, which no longer works, set it to the current position (rpos). this makes the shgetc macro work with no change, but it breaks shunget, which can no longer look at the value of shend to determine whether to back up. Szabolcs Nagy suggested a solution which I'm using here: setting shlim to a negative value is inexpensive to test at shunget time, and automatically re-trips the cnt>=shlim stop condition in __shgetc no matter what the original limit was.
2019-03-13fix namespace violation in dependencies of mtx_lockRich Felker-1/+1
commit 2de29bc994029b903a366b8a4a9f8c3c3ee2be90 left behind one reference to pthread_mutex_trylock. fixing this also improves code generation due to the namespace-safe version being hidde.
2019-03-13handle labels with 8-bit byte values in dn_skipnameRyan Fairfax-2/+5
The original logic considered each byte until it either found a 0 value or a value >= 192. This means if a string segment contained any byte >= 192 it was interepretted as a compressed segment marker even if it wasn't in a position where it should be interpretted as such. The fix is to adjust dn_skipname to increment by each segments size rather than look at each character. This avoids misinterpretting string segment characters by not considering those bytes.
2019-03-12setvbuf: return failure if mode is invalidA. Wilcox-1/+3
POSIX requires setvbuf to return non-zero if `mode` is not one of _IONBF, _IOLBF, or _IOFBF.
2019-03-12make FILE a complete type for pre-C11 standard profilesRich Felker-0/+11
C11 removed the requirement that FILE be a complete type, which was deemed erroneous, as part of the changes introduced by N1439 regarding completeness of types (see footnote 6 for specific mention of FILE). however the current version of POSIX is still based on C99 and incorporates the old requirement that FILE be a complete type. expose an arbitrary, useless complete type definition because the actual object used to represent FILE streams cannot be public/ABI. thanks to commit 13d1afa46f8098df290008c681816c9eb89ffbdb, we now have a framework for suppressing the public complete-type definition of FILE when stdio.h is included internally, so that a different internal definition can be provided. this is perfectly well-defined, since the same struct tag can refer to different types in different translation units. it would be a problem if the implementation were accessing the application's FILE objects or vice versa, but either would be undefined behavior.
2019-03-05don't reject unknown/future flags in sigaltstack, allow SS_AUTODISARMRich Felker-1/+1
historically, and likely accidentally, sigaltstack was specified to fail with EINVAL if any flag bit other than SS_DISABLE was set. the resolution of Austin Group issue 1187 fixes this so that the requirement is only to fail for SS_ONSTACK (which cannot be set) or "invalid" flags. Linux fails on the kernel side for invalid flags, but historically accepts SS_ONSTACK as a no-op, so it needs to be rejected in userspace still. with this change, the Linux-specific SS_AUTODISARM, provided since commit 9680e1d03a794b0e0d5815c749478228ed40a36d but unusable due to rejection at runtime, is now usable.
2019-02-22add membarrier syscall wrapper, refactor dynamic tls install to use itRich Felker-3/+88
the motivation for this change is twofold. first, it gets the fallback logic out of the dynamic linker, improving code readability and organization. second, it provides application code that wants to use the membarrier syscall, which depends on preregistration of intent before the process becomes multithreaded unless unbounded latency is acceptable, with a symbol that, when linked, ensures that this registration happens.
2019-02-22make thread list lock a recursive lockRich Felker-11/+21
this is a prerequisite for factoring the membarrier fallback code into a function that can be called from a context with the thread list already locked or independently.
2019-02-20fix spurious undefined behavior in getaddrinfoRich Felker-3/+2
addressing &out[k].sa was arguably undefined, despite &out[k] being defined the slot one past the end of an array, since the member access .sa is intervening between the [] operator and the & operator.
2019-02-20fix invalid free of partial addrinfo list with multiple servicesRich Felker-1/+1
the backindex stored by getaddrinfo to allow freeaddrinfo to perform partial-free wrongly used the address result index, rather than the output slot index, and thus was only valid when they were equal (nservs==1). patch based on report with proposed fix by Markus Wichmann.
2019-02-18install dynamic tls synchronously at dlopen, streamline accessRich Felker-118/+7
previously, dynamic loading of new libraries with thread-local storage allocated the storage needed for all existing threads at load-time, precluding late failure that can't be handled, but left installation in existing threads to take place lazily on first access. this imposed an additional memory access and branch on every dynamic tls access, and imposed a requirement, which was not actually met, that the dynamic tlsdesc asm functions preserve all call-clobbered registers before calling C code to to install new dynamic tls on first access. the x86[_64] versions of this code wrongly omitted saving and restoring of fpu/vector registers, assuming the compiler would not generate anything using them in the called C code. the arm and aarch64 versions saved known existing registers, but failed to be future-proof against expansion of the register file. now that we track live threads in a list, it's possible to install the new dynamic tls for each thread at dlopen time. for the most part, synchronization is not needed, because if a thread has not synchronized with completion of the dlopen, there is no way it can meaningfully request access to a slot past the end of the old dtv, which remains valid for accessing slots which already existed. however, it is necessary to ensure that, if a thread sees its new dtv pointer, it sees correct pointers in each of the slots that existed prior to the dlopen. my understanding is that, on most real-world coherency architectures including all the ones we presently support, a built-in consume order guarantees this; however, don't rely on that. instead, the SYS_membarrier syscall is used to ensure that all threads see the stores to the slots of their new dtv prior to the installation of the new dtv. if it is not supported, the same is implemented in userspace via signals, using the same mechanism as __synccall. the __tls_get_addr function, variants, and dynamic tlsdesc asm functions are all updated to remove the fallback paths for claiming new dynamic tls, and are now all branch-free.
2019-02-17fix data race between new pthread_key_delete and dtor executionRich Felker-2/+4
access to clear the entry in each thread's tsd array for the key being deleted was not synchronized with __pthread_tsd_run_dtors. I probably made this mistake from a mistaken belief that the thread list lock was held during the latter, which of course is not possible since it executes application code in a still-live-thread context. while we're at it, expand the interval during which signals are blocked to cover taking the write lock on key_lock, so that a signal at an inopportune time doesn't block forward progress of readers.
2019-02-16introduce namespace-safe rwlock aliases; use in pthread_key_createRich Felker-20/+41
commit 84d061d5a31c9c773e29e1e2b1ffe8cb9557bc58 inadvertently introduced namespace violations by using the pthread-namespace rwlock functions in pthread_key_create, which is in turn used for C11 tss. fix that and possible future uses of rwlocks elsewhere.
2019-02-16rewrite pthread_key_delete to use global thread listRich Felker-75/+19
with the availability of the thread list, there is no need to mark tsd key slots dirty and clean them up only when a free slot can't be found. instead, directly iterate threads and clear any value associated with the key being deleted. no synchronization is necessary for the clearing, since there is no way the slot can be accessed without having synchronized with the creation of a new key occupying the same slot, which is already sequenced after and synchronized with the deletion of the old key.
2019-02-16rewrite __synccall in terms of global thread listRich Felker-124/+59
the __synccall mechanism provides stop-the-world synchronous execution of a callback in all threads of the process. it is used to implement multi-threaded setuid/setgid operations, since Linux lacks them at the kernel level, and for some other less-critical purposes. this change eliminates dependency on /proc/self/task to determine the set of live threads, which in addition to being an unwanted dependency and a potential point of resource-exhaustion failure, turned out to be inaccurate. test cases provided by Alexey Izbyshev showed that it could fail to reflect newly created threads. due to how the presignaling phase worked, this usually yielded a deadlock if hit, but in the worst case it could also result in threads being silently missed (allowed to continue running without executing the callback).
2019-02-15track all live threads in an AS-safe, fully-consistent linked listRich Felker-43/+94
the hard problem here is unlinking threads from a list when they exit without creating a window of inconsistency where the kernel task for a thread still exists and is still executing instructions in userspace, but is not reflected in the list. the magic solution here is getting rid of per-thread exit futex addresses (set_tid_address), and instead using the exit futex to unlock the global thread list. since pthread_join can no longer see the thread enter a detach_state of EXITED (which depended on the exit futex address pointing to the detach_state), it must now observe the unlocking of the thread list lock before it can unmap the joined thread and return. it doesn't actually have to take the lock. for this, a __tl_sync primitive is offered, with a signature that will allow it to be enhanced for quick return even under contention on the lock, if needed. for now, the exiting thread always performs a futex wake on its detach_state. a future change could optimize this out except when there is already a joiner waiting. initial/dynamic variants of detached state no longer need to be tracked separately, since the futex address is always set to the global list lock, not a thread-local address that could become invalid on detached thread exit. all detached threads, however, must perform a second sigprocmask syscall to block implementation-internal signals, since locking the thread list with them already blocked is not permissible. the arch-independent C version of __unmapself no longer needs to take a lock or setup its own futex address to release the lock, since it must necessarily be called with the thread list lock already held, guaranteeing exclusive access to the temporary stack. changes to libc.threads_minus_1 no longer need to be atomic, since they are guarded by the thread list lock. it is largely vestigial at this point, and can be replaced with a cheaper boolean indicating whether the process is multithreaded at some point in the future.
2019-02-15always block signals for starting new threads, refactor start argsRich Felker-68/+56
whether signals need to be blocked at thread start, and whether unblocking is necessary in the entry point function, has historically depended on intricacies of the cancellation design and on whether there are scheduling operations to perform on the new thread before its successful creation can be committed. future changes to track an AS-safe list of live threads will require signals to be blocked whenever changes are made to the list, so ... prior to commits b8742f32602add243ee2ce74d804015463726899 and 40bae2d32fd6f3ffea437fa745ad38a1fe77b27e, a signal mask for the entry function to restore was part of the pthread structure. it was removed to trim down the size of the structure, which both saved a small amount of stack space and improved code generation on archs where small immediate displacements are less costly than arbitrary ones, by limiting the range of offsets between the base of the thread structure, its members, and the thread pointer. these commits moved the saved mask to a special structure used only when special scheduling was needed, in which case the pthread_create caller and new thread had to synchronize with each other and could use this memory to pass a mask. this commit partially reverts the above two commits, but instead of putting the mask back in the pthread structure, it moves all "start argument" members out of the pthread structure, trimming it down further, and puts them in a separate structure passed on the new thread's stack. the code path for explicit scheduling of the new thread is also changed to synchronize with the calling thread in such a way to avoid spurious futex wakes.
2019-02-15for SIGEV_THREAD timer threads, replace signal handler with sigwaitinfoRich Felker-21/+16
this eliminates some ugly hacks that were repurposing the start function and start argument fields in the pthread structure for timer use, and the need to longjmp out of a signal handler.
2019-02-15defer free of thread-local dlerror buffers from inconsistent contextRich Felker-2/+20
__dl_thread_cleanup is called from the context of an exiting thread that is not in a consistent state valid for calling application code. since commit c9f415d7ea2dace5bf77f6518b6afc36bb7a5732, it's possible (and supported usage) for the allocator to have been replaced by the application, so __dl_thread_cleanup can no longer call free. instead, reuse the message buffer as a linked-list pointer, and queue it to be freed the next time any dynamic linker error message is generated.
2019-02-13fix behavior of gets when input line contains a null byteRich Felker-3/+8
the way gets was implemented in terms of fgets, it used the location of the null termination to determine where to find and remove the newline, if any. an embedded null byte prevented this from working. this also fixes a one-byte buffer overflow, whereby when gets read an N-byte line (not counting newline), it would store two null terminators for a total of N+2 bytes. it's unlikely that anyone would care that a function whose use is pretty much inherently a buffer overflow writes too much, but it could break the only possible correct uses of this function, in conjunction with input of known format from a trusted/same-privilege-domain source, where the buffer length may have been selected to exactly match a line length contract. there seems to be no correct way to implement gets in terms of a single call to fgets or scanf, and using multiple calls would require explicit locking, so we might as well just write the logic out explicitly character-at-a-time. this isn't fast, but nobody cares if a catastrophically unsafe function that's so bad it was removed from the C language is fast.
2019-02-12redesign robust mutex states to eliminate data races on type fieldRich Felker-12/+23
in order to implement ENOTRECOVERABLE, the implementation has traditionally used a bit of the mutex type field to indicate that it's recovered after EOWNERDEAD and will go into ENOTRECOVERABLE state if pthread_mutex_consistent is not called before unlocking. while it's only the thread that holds the lock that needs access to this information (except possibly for the sake of pthread_mutex_consistent choosing between EINVAL and EPERM for erroneous calls), the change to the type field is formally a data race with all other threads that perform any operation on the mutex. no individual bits race, and no write races are possible, so things are "okay" in some sense, but it's still not good. this patch moves the recovery/consistency state to the mutex owner/lock field which is rightfully mutable. bit 30, the same bit the kernel uses with a zero owner to indicate that the previous owner died holding the lock, is now used with a nonzero owner to indicate that the mutex is held but has not yet been marked consistent. note that the kernel ABI also reserves bit 29 not to appear in any tid, so the sentinel value we use for ENOTRECOVERABLE, 0x7fffffff, does not clash with any tid plus bit 30.
2019-02-07fail fdopendir for O_PATH file descriptorsRich Felker-0/+4
fdopendir is specified to fail with EBADF if the file descriptor passed is not open for reading. while O_PATH is an extension and arguably exempt from this requirement, it's used, albeit incompletely, to implement O_SEARCH, and fdopendir should fail when passed an O_SEARCH file descriptor. the new check is performed after fstat so that we don't have to consider the possibility that the fd is invalid. an alternate solution would be attempting to pre-fill the buffer using getdents, which would fail with EBADF for us, but that seems more complex and error-prone and involves either code duplication or refactoring, so the simple fix with an additional inexpensive syscall is what I've made for now.
2019-02-07locale: ensure dcngettext() preserves errnoA. Wilcox-0/+3
Some packages call gettext to format a message to be sent to perror. If the currently set user locale points to a non-existent .mo file, open via __map_file in dcngettext will set errno to ENOENT. Maintainer's notes: Non-modification of errno is a documented part of the interface contract for the GNU version of this function and likely other versions. The issue being fixed here seems to be a regression from commit 1b52863e244ecee5b5935b6d36bb9e6efe84c035, which enabled setting of errno from __map_file.
2019-01-21fix call to __pthread_tsd_run_dtors with too many argumentsRich Felker-1/+1
commit a6054e3c94aa0491d7366e4b05ae0d73f661bfe2 removed the argument, making it a constraint violation to pass one. caught by cparser/firm; other compilers seem to ignore it.
2019-01-16fix unintended linking dependency of pthread_key_create on __synccallRich Felker-0/+6
commit 84d061d5a31c9c773e29e1e2b1ffe8cb9557bc58 attempted to do this already, but omitted from pthread_key_create.c the weak definition of __pthread_key_delete_synccall, so that the definition provided by pthread_key_delete.c was always pulled in. based on patch by Markus Wichmann, but with a weak alias rather than weak reference for consistency/policy about dependence on tooling features.
2018-12-28halt getspnam[_r] search on error accessing TCB shadowRich Felker-0/+2
fallback to /etc/shadow should happen only when the entry is not found in the TCB shadow. otherwise transient errors or permission errors can cause inconsistent results.
2018-12-28don't set errno or return an error when getspnam[_r] finds no entryRich Felker-3/+9
this case is specified as success with a null result, rather than an error, and errno is not to be set on success.
2018-12-19make sem_wait and sem_timedwait interruptible by signalsRich Felker-1/+1
this reverts commit c0ed5a201b2bdb6d1896064bec0020c9973db0a1, which was based on a mistaken reading of POSIX due to inconsistency between the description (which requires return upon interruption by a signal) and the errors list (which wrongly lists EINTR as "may fail"). since the previously-introduced behavior was a workaround for an old kernel bug to ensure safety of correct programs that were not hardened against the bug, an effort has been made to preserve it for programs which do not use interrupting signal handlers. the stage for this was set in commit a63c0104e496f7ba78b64be3cd299b41e8cd427f, which makes the futex __timedwait backend suppress EINTR if it's seen when no interrupting signal handlers have been installed. based loosely on a patch submitted by Orivej Desh, but with unnecessary additional changes removed.
2018-12-18don't fail pthread_sigmask/sigprocmask on invalid how when set is nullRich Felker-1/+1
the resolution of Austin Group issue #1132 changes the requirement to fail so that it only applies when the set argument (new mask) is non-null. this change was made for consistency with the description, which specified "if set is a null pointer, the value of the argument how is not significant".
2018-12-18add __timedwait backend workaround for old kernels where futex EINTRsRich Felker-0/+15
prior to linux 2.6.22, futex wait could fail with EINTR even for non-interrupting (SA_RESTART) signals. this was no problem provided the caller simply restarted the wait, but sem_[timed]wait is required by POSIX to return when interrupted by a signal. commit a113434cd68ce30642c4995b1caadcd084be6f09 introduced this behavior, and commit c0ed5a201b2bdb6d1896064bec0020c9973db0a1 reverted it based on a mistaken belief that it was not required. this belief stems from a bug in the specification: the description requires the function to return when interrupted, but the errors section marks EINTR as a "may fail" condition rather than a "shall fail" one. since there does seem to be significant value in the change made in commit c0ed5a201b2bdb6d1896064bec0020c9973db0a1, making it so that programs that call sem_wait without checking for EINTR don't silently make forward progress without obtaining the semaphore or treat it as a fatal error and abort, add a behind-the-scenes mechanism in the __timedwait backend to suppress EINTR in programs that have never installed interrupting signal handlers, and have sigaction track and report this state. this way the semaphore code is not cluttered by workarounds and can be updated (to be done in next commit) to reflect the high-level logic for conforming behavior. these changes are based loosely on a patch by Markus Wichmann, with the main changes being atomic update to flag object and moving the workaround from sem_timedwait to the __timedwait futex backend.
2018-12-11on failed aio submission, set aiocb error and return valueRich Felker-2/+4
it's not clear whether this is required, but it seems arguable that it should happen. for example aio_suspend is supposed to return immediately if any of the operations has "completed", which includes ending with an error status asynchonously and might also be interpreted to include doing so synchronously.
2018-12-11don't create aio queue/map structures for invalid file descriptorsRich Felker-4/+8
the map structures in particular are permanent once created, and thus a large number of aio function calls with invalid file descriptors could exhaust memory, whereas, assuming normal resource limits, only a very small number of entries ever need to be allocated. check validity of the fd before allocating anything new, so that allocation of large amounts of memory is only possible when resource limits have been increased and a large number of files are actually open. this change also improves error reporting for bad file descriptors to happen at the time the aio submission call is made, as opposed to asynchronously.
2018-12-11move aio queue allocation from io thread to submitting threadRich Felker-16/+21
since commit c9f415d7ea2dace5bf77f6518b6afc36bb7a5732, it has been possible that the allocator is application-provided code, which cannot necessarily run safely on io thread stacks, and which should not be able to see the existence of io threads, since they are an implementation detail. instead of having the io thread request and possibly allocate its queue (and the map structures leading to it), make the submitting thread responsible for this, and pass the queue pointer into the io thread via its args structure. this eliminates the only early error case in io threads, making it no longer necessary to pass an error status back to the submitting thread via the args structure.
2018-12-09fix and future-proof against stack overflow in aio io threadsRich Felker-1/+12
aio threads not using SIGEV_THREAD notification are created with small stacks and no guard page, which is possible since they only run the code for the requested io operation, not any application code. the motivation is not creating a lot of VMAs. however, the io thread needs to be able to receive a cancellation signal in case aio_cancel (implemented via pthread_cancel) is called. this requires sufficient stack space for a signal frame, which PTHREAD_STACK_MIN does not necessarily include. in principle MINSIGSTKSZ from signal.h should give us sufficient space for a signal frame, but the value is incorrect on some existing archs due to kernel addition of new vector register support without consideration for impact on ABI. some powerpc models exceed MINSIGSTKSZ by about 0.5k, and x86[_64] with AVX-512 can exceed it by up to about 1.5k. so use MINSIGSTKSZ+2048 to allow for the discrepancy plus some working space. unfortunately, it's possible that signal frame sizes could continue to grow, and some archs (aarch64) explicitly specify that they may. passing of a runtime value for MINSIGSTKSZ via AT_MINSIGSTKSZ in the aux vector was added to aarch64 linux, and presumably other archs will use this mechanism to report if they further increase the signal frame size. when AT_MINSIGSTKSZ is present, assume it's correct, so that we only need a small amount of working space in addition to it; in this case just add 512.
2018-12-09add namespace-safe version of getauxval for internal useRich Felker-1/+13
2018-12-09fix wordexp not to read past end of string ending with lone backslashRich Felker-1/+1
2018-12-02fix memccpy to not access buffer past given sizeQuentin Rameau-1/+1
memccpy would return a pointer over the given size when c is not found in the source buffer and n reaches 0.
2018-11-08optimize two-way strstr and memmem bad character shiftRich Felker-2/+2
first, the condition (mem && k < p) is redundant, because mem being nonzero implies the needle is periodic with period exactly p, in which case any byte that appears in the needle must appear in the last p bytes of the needle, bounding the shift (k) by p. second, the whole point of replacing the shift k by mem (=l-p) is to prevent shifting by less than mem when discarding the memory on shift, in which case linear time could not be guaranteed. but as written, the check also replaced shifts greater than mem by mem, reducing the benefit of the shift. there is no possible benefit to this reduction of the shift; since mem is being cleared, the full shift is valid and more optimal. so only replace the shift by mem when it would be less than mem.
2018-11-02fix regression in setlocale for LC_ALL with per-category settingRich Felker-1/+1
commit d88e5dfa8b989dafff4b748bfb3cba3512c8482e inadvertently changed the argument pased to __get_locale from part (the current ;-delimited component) to name (the full string).
2018-11-02fix failure to flush stderr when fflush(0) is calledRich Felker-1/+4
commit ddc947eda311331959c73dbc4491afcfe2326346 fixed the corresponding bug for exit which was introduced when commit 0b80a7b0404b6e49b0b724e3e3fe0ed5af3b08ef added support for caller-provided buffers, making it possible for stderr to be a buffered stream.
2018-11-02fix deadlock and buffered data loss race in fcloseRich Felker-13/+19
fflush(NULL) and __stdio_exit lock individual FILEs while holding the open file list lock to walk the list. since fclose first locked the FILE to be closed, then the ofl lock, it could deadlock with these functions. also, because fclose removed the FILE to be closed from the open file list before flushing and closing it, a concurrent fclose or exit could complete successfully before fclose flushed the FILE it was closing, resulting in data loss. reorder the body of fclose to first flush and close the file, then remove it from the open file list only after unlocking it. this creates a window where consumers of the open file list can see dead FILE objects, but in the absence of undefined behavior on the part of the application, such objects will be in an inactive-buffer state and processing them will have no side effects. __unlist_locked_file is also moved so that it's performed only for non-permanent files. this change is not necessary, but preserves consistency (and thereby provides safety/hardening) in the case where an application uses one of the standard streams after closing it while holding an explicit lock on it. such usage is of course undefined behavior.