about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* sys/mman.h: add new hugetlb mmap flags from linux v4.19Szabolcs Nagy2019-03-132-0/+4
| | | | | aarch64 supports 32MB and 512MB hugetlb page sizes too. added in linux commit 20916d4636a9b3c1bf562b305f91d126771edaf9
* arm: add io_pgetevents syscall number from v4.19Szabolcs Nagy2019-03-131-0/+1
| | | | wired up in linux commit 73aeb2cbcdc9be391b3d32a55319a59ce425426f
* aarch64, or1k: define rseq syscall number following linux v4.19Szabolcs Nagy2019-03-132-0/+2
| | | | added in linux commit db7a2d1809a5b6b08d138ff68837f805fc073351
* elf.h: add new mips core dump note values from linux v4.19Szabolcs Nagy2019-03-131-0/+2
| | | | | | | | NT_MIPS_FP_MODE is new in linux commit 1ae22a0e35636efceab83728ba30b013df761592 NT_MIPS_DSP is new in linux commit 44109c60176ae73924a42a6bef64ef151aba9095
* netinet/udp.h: add UDP_ENCAP_RXRPC from linux v4.19Szabolcs Nagy2019-03-131-0/+1
| | | | | used for optimizing the rxrpc protocol added in linux commit 5271953cad31b97dea80f848c16e96ad66401199
* netinet/tcp.h: add tcp_info fields from linux v4.19Szabolcs Nagy2019-03-131-0/+8
| | | | | | | | | | | | new fields for RFC 4898 tcp stats in linux tcpi_bytes_sent added in commit ba113c3aa79a7f941ac162d05a3620bdc985c58d tcpi_bytes_retrans added in commit fb31c9b9f6c85b1bad569ecedbde78d9e37cd87b tcpi_dsack_dups added in commit 7e10b6554ff2ce7f86d5d3eec3af5db8db482caa tcpi_reord_seen added in commit 7ec65372ca534217b53fd208500cf7aac223a383 The new fields change the size of a public struct and thus an ABI break, but this is how the getsockopt TCP_INFO api is designed: the tcp_info type must only be used with a length parameter in extern interfaces.
* sys/inotify.h: add IN_MASK_CREATE from linux v4.19Szabolcs Nagy2019-03-131-0/+1
| | | | | | inotify_add_watch flag to prevent modifying existing watch descriptors, when used on an already watched inode it fails with EEXIST. added in linux commit 4d97f7d53da7dc830dbf416a3d2a6778d267ae68
* sys/socket.h: add SO_TXTIME from linux v4.19Szabolcs Nagy2019-03-131-0/+2
| | | | added in linux commit 80b14dee2bea128928537d61c333f24cb8cbb62f
* handle labels with 8-bit byte values in dn_skipnameRyan Fairfax2019-03-131-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.
* fix POSIX_FADV_DONTNEED/_NOREUSE on s390xJonathan Neuschäfer2019-03-132-0/+5
| | | | | | | | | On s390x, POSIX_FADV_DONTNEED and POSIX_FADV_NOREUSE have different values than on all other architectures that Linux supports. Handle this difference by wrapping their definitions in include/fcntl.h in #ifdef, so that arch/s390x/bits/fcntl.h can override them.
* expose TSVTX unconditionally in tar.hRich Felker2019-03-131-4/+0
| | | | | | | | | | as noted in Austin Group issue #1236, the XSI shading for TSVTX is misplaced in the html version of the standard; it was only supposed to be on the description text. the intent was that the definition always be visible, which is reflected in the pdf version of the standard. this reverts commits d93c0740d86aaf7043e79b942a6c0b3f576af4c8 and 729fef0a9358e2f6f1cd8c75a1a0f7ee48b08c95.
* setvbuf: return failure if mode is invalidA. Wilcox2019-03-121-1/+3
| | | | | POSIX requires setvbuf to return non-zero if `mode` is not one of _IONBF, _IOLBF, or _IOFBF.
* make FILE a complete type for pre-C11 standard profilesRich Felker2019-03-125-0/+20
| | | | | | | | | | | | | | | | | | | | 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.
* fix invalid-/double-/use-after-free in new dlopen ctor executionRich Felker2019-03-101-1/+2
| | | | | | | | | | | | | | this affected the error path where dlopen successfully found and loaded the requested dso and all its dependencies, but failed to resolve one or more relocations, causing the operation to fail after storage for the ctor queue was allocated. commit 188759bbee057aa94db2bbb7cf7f5855f3b9ab53 wrongly put the free for the ctor_queue array in the error path inside a loop over each loaded dso that needed to be backed-out, rather than just doing it once. in addition, the exit path also observed the ctor_queue pointer still being nonzero, and would attempt to call ctors on the backed-out dsos unless the double-free crashed the process first.
* don't reject unknown/future flags in sigaltstack, allow SS_AUTODISARMRich Felker2019-03-051-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.
* avoid malloc of ctor queue for programs with no external depsRich Felker2019-03-031-2/+9
| | | | | | together with the previous two commits, this completes restoration of the property that dynamic-linked apps with no external deps and no tls have no failure paths before entry.
* avoid malloc of deps arrays for ldso and vdsoRich Felker2019-03-031-0/+3
| | | | | | neither has or can have any dependencies, but since commit 403555690775f7c8806372644f543518e6664e3b, gratuitous zero-length deps arrays were being allocated for them. use a dummy array instead.
* avoid malloc of deps array for programs with no external depsRich Felker2019-03-031-3/+10
| | | | | | | | | traditionally, we've provided a guarantee that dynamic-linked applications with no external dependencies (nothing but libc) and no thread-local storage have no failure paths before the entry point. normally, thanks to reclaim_gaps, such a malloc will not require a syscall anyway, but if segment alignment is unlucky, it might. use a builtin array for this common special case.
* fix malloc misuse for startup ctor queue, breakage on fdpic archsRich Felker2019-03-031-5/+9
| | | | | | | | | | | | | in the case where malloc is being replaced, it's not valid to call malloc between final relocations and main app's crt1 entry point; on fdpic archs the main app's entry point will not yet have performed the self-fixups necessary to call its code. to fix, reorder queue_ctors before final relocations. an alternative solution would be doing the allocation from __libc_start_init, after the entry point but before any ctors run. this is less desirable, since it would leave a call to malloc that might be provided by the application happening at startup when doing so can be easily avoided.
* synchronize shared library dtor exec against concurrent loads/ctorsRich Felker2019-03-031-1/+17
| | | | | | | | | | | | | | | previously, going way back, there was simply no synchronization here. a call to exit concurrent with ctor execution from dlopen could cause a dtor to execute concurrently with its corresponding ctor, or could cause dtors for newly-constructed libraries to be skipped. introduce a shutting_down state that blocks further ctor execution, producing the quiescence the dtor execution loop needs to ensure any kind of consistency, and that blocks further calls to dlopen so that a call into dlopen from a dtor cannot deadlock. better approaches to some of this may be possible, but the changes here at least make things safe.
* overhaul shared library ctor execution for dependency order, concurrencyRich Felker2019-03-031-17/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | previously, shared library constructors at program start and dlopen time were executed in reverse load order. some libraries, however, rely on a depth-first dependency order, which most other dynamic linker implementations provide. this is a much more reasonable, less arbitrary order, and it turns out to have much better properties with regard to how slow-running ctors affect multi-threaded programs, and how recursive dlopen behaves. this commit builds on previous work tracking direct dependencies of each dso (commit 403555690775f7c8806372644f543518e6664e3b), and performs a topological sort on the dependency graph at load time while the main ldso lock is held and before success is committed, producing a queue of constructors needed by the newly-loaded dso (or main application). in the case of circular dependencies, the dependency chain is simply broken at points where it becomes circular. when the ctor queue is run, the init_fini_lock is held only for iteration purposes; it's released during execution of each ctor, so that arbitrarily-long-running application code no longer runs with a lock held in the caller. this prevents a dlopen with slow ctors in one thread from arbitrarily delaying other threads that call dlopen. fully-independent ctors can run concurrently; when multiple threads call dlopen with a shared dependency, one will end up executing the ctor while the other waits on a condvar for it to finish. another corner case improved by these changes is recursive dlopen (call from a ctor). previously, recursive calls to dlopen could cause a ctor for a library to be executed before the ctor for its dependency, even when there was no relation between the calling library and the library it was loading, simply due to the naive reverse-load-order traversal. now, we can guarantee that recursive dlopen in non-circular-dependency usage preserves the desired ctor execution order properties, and that even in circular usage, at worst the libraries whose ctors call dlopen will fail to have completed construction when ctors that depend on them run. init_fini_lock is changed to a normal, non-recursive mutex, since it is no longer held while calling back into application code.
* record preloaded libraries as direct pseudo-dependencies of main appRich Felker2019-03-021-4/+11
| | | | | | this makes calling dlsym on the main app more consistent with the global symbol table (load order), and is a prerequisite for dependency-order ctor execution to work correctly with LD_PRELOAD.
* fix unsafety of new ldso dep tracking in presence of malloc replacementRich Felker2019-03-021-1/+13
| | | | | | | commit 403555690775f7c8806372644f543518e6664e3b introduced runtime realloc of an array that may have been allocated before symbols were resolved outside of libc, which is invalid if the allocator has been replaced. track this condition and manually copy if needed.
* fix and overhaul dlsym depedency order, always record direct depsRich Felker2019-02-271-34/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dlsym with an explicit handle is specified to use "dependency order", a breadth-first search rooted at the argument. this has always been implemented by iterating a flattened dependency list built at dlopen time. however, the logic for building this list was completely wrong except in trivial cases; it simply used the list of libraries loaded since a given library, and their direct dependencies, as that library's dependencies, which could result in misordering, wrongful omission of deep dependencies from the search, and wrongful inclusion of unrelated libraries in the search. further, libraries did not have any recorded list of resolved dependencies until they were explicitly dlopened, meaning that DT_NEEDED entries had to be resolved again whenever a library participated as a dependency of more than one dlopened library. with this overhaul, the resolved direct dependency list of each library is always recorded when it is first loaded, and can be extended to a full flattened breadth-first search list if dlopen is called on the library. the extension is performed using the direct dependency list as a queue and appending copies of the direct dependency list of each dependency in the queue, excluding duplicates, until the end of the queue is reached. the direct deps remain available for future use as the initial subarray of the full deps array. first-load logic in dlopen is updated to match these changes, and clarified.
* fix crash/misbehavior from oob read in new dynamic tls installationRich Felker2019-02-271-1/+1
| | | | | | | | | | | | | code introduced in commit 9d44b6460ab603487dab4d916342d9ba4467e6b9 wrongly attempted to read past the end of the currently-installed dtv to determine if a dso provides new, not-already-installed tls. this logic was probably leftover from an earlier draft of the code that wrongly installed the new dtv before populating it. it would work if we instead queried the new, not-yet-installed dtv, but instead, replace the incorrect check with a simple range check against old_cnt. this also catches modules that have no tls at all with a single condition.
* fix crash in new dynamic tls installation when last dep lacks tlsRich Felker2019-02-251-1/+4
| | | | | | | | | | | | | | | code introduced in commit 9d44b6460ab603487dab4d916342d9ba4467e6b9 wrongly assumed the dso list tail was the right place to find new dtv storage. however, this is only true if the last-loaded dependency has tls. the correct place to get it is the dso corresponding to the tls module list tail. introduce a container_of macro to get it, and use it. ultimately, dynamic tls allocation should be refactored so that this is not an issue. there is no reason to be allocating new dtv space at each load_library; instead it could happen after all new libraries have been loaded but before they are committed. such changes may be made later, but this commit fixes the present regression.
* add membarrier syscall wrapper, refactor dynamic tls install to use itRich Felker2019-02-226-35/+111
| | | | | | | | | | 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.
* make thread list lock a recursive lockRich Felker2019-02-221-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.
* fix loop logic cruft in dynamic tls installationRich Felker2019-02-221-1/+1
| | | | | | | | commit 9d44b6460ab603487dab4d916342d9ba4467e6b9 inadvertently contained leftover logic from a previous approach to the fallback signaling loop. it had no adverse effect, since j was always nonzero if the loop body was reachable, but it makes no sense to be there with the current approach to avoid signaling self.
* fix spurious undefined behavior in getaddrinfoRich Felker2019-02-201-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.
* fix invalid free of partial addrinfo list with multiple servicesRich Felker2019-02-201-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.
* install dynamic tls synchronously at dlopen, streamline accessRich Felker2019-02-189-160/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* fix data race between new pthread_key_delete and dtor executionRich Felker2019-02-171-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.
* introduce namespace-safe rwlock aliases; use in pthread_key_createRich Felker2019-02-169-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.
* rewrite pthread_key_delete to use global thread listRich Felker2019-02-162-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.
* rewrite __synccall in terms of global thread listRich Felker2019-02-163-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).
* track all live threads in an AS-safe, fully-consistent linked listRich Felker2019-02-157-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.
* always block signals for starting new threads, refactor start argsRich Felker2019-02-154-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.
* for SIGEV_THREAD timer threads, replace signal handler with sigwaitinfoRich Felker2019-02-152-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.
* defer free of thread-local dlerror buffers from inconsistent contextRich Felker2019-02-151-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.
* fix behavior of gets when input line contains a null byteRich Felker2019-02-131-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.
* redesign robust mutex states to eliminate data races on type fieldRich Felker2019-02-124-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.
* fail fdopendir for O_PATH file descriptorsRich Felker2019-02-071-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.
* update line discipline constantsBobby Bingham2019-02-071-0/+12
|
* move arch-invariant definitions out of bits/ioctl.hBobby Bingham2019-02-078-682/+98
|
* locale: ensure dcngettext() preserves errnoA. Wilcox2019-02-071-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.
* release 1.1.21 v1.1.21Rich Felker2019-01-212-1/+53
|
* fix call to __pthread_tsd_run_dtors with too many argumentsRich Felker2019-01-211-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.
* configure: accept ppc[64] as alias for powerpc[64] in gcc tuplesRich Felker2019-01-191-2/+2
| | | | | apparently some distros use this form, and it seems to be supported in the gcc build system.
* fix unintended linking dependency of pthread_key_create on __synccallRich Felker2019-01-161-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.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-16 22:03:44 +0000