about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
...
* getservbyport_r: fix out-of-bounds buffer readAlexey Izbyshev2023-02-281-1/+1
| | | | | | | | | | | | If the buffer passed to getservbyport_r is just enough to store two pointers after aligning it, getnameinfo is called with buflen == 0 (which means that service name is not needed) and trivially succeeds. Then, strtol is called on the address just past the buffer end, and if it doesn't happen to find the port number there, getservbyport_r spuriously succeeds and returns the same bad address to the caller. Fix this by ensuring that buflen is at least 1 when passed to getnameinfo.
* getifaddrs: fix UB via taking address of null pointer union dereferenceAlexey Izbyshev2023-02-281-7/+7
| | | | | | | | getifaddrs computes &ctx->first->ifa even if ctx->first is NULL. While this shouldn't be possible on the success path because the loopback interface is hardcoded into the kernel, this is still possible on the error path (for example, if __rtnetlink_enumerate couldn't create a socket due to exceeding the fd limit).
* accept4: don't fall back to accept if we got unknown flagsAlexey Izbyshev2023-02-281-0/+4
| | | | | | | | | | | | accept4 emulation via accept ignores unknown flags, so it can spuriously succeed instead of failing (or succeed without doing the action implied by an unknown flag if it's added in a future kernel). Worse, unknown flags trigger the fallback code even on modern kernels if the real accept4 syscall returns EINVAL, because this is indistinguishable from socketcall returning EINVAL due to lack of accept4 support. Fix this by always failing with EINVAL if unknown flags are present and the syscall is missing or failed with EINVAL.
* fix potential read past end of buffer in getnameinfo host name lookupAlexey Izbyshev2023-02-271-0/+1
| | | | | | | This is completely analoguous to commit 633183b5d1c2. Similar code called from __lookup_name is not affected because it checks that the line contains the host name surrounded by blanks.
* dns: fix workaround for systems defaulting to ipv6-only socketsAlexey Izbyshev2023-02-271-15/+16
| | | | | | | | When IPv6 nameservers are present, __res_msend_rc attempts to disable IPV6_V6ONLY socket option to ensure that it can communicate with IPv4 nameservers (if they are present too) via IPv4-mapped IPv6 addresses. However, this option can't be disabled on bound sockets, so setsockopt always fails.
* dns: handle early eof in tcp fallbackAlexey Izbyshev2023-02-271-1/+1
| | | | | | | | A zero returned from recvmsg is currently treated as if some data were received, so if a DNS server closes its TCP socket before sending the full answer, __res_msend_rc will spin until the timeout elapses because POLLIN event will be reported on each poll. Fix this by treating an early EOF as an error.
* prevent CNAME/PTR parsing from reading data past the response endAlexey Izbyshev2023-02-274-7/+7
| | | | | | | | DNS parsing callbacks pass the response buffer end instead of the actual response end to dn_expand, so a malformed DNS response can use message compression to make dn_expand jump past the response end and attempt to parse uninitialized parts of that buffer, which might succeed and return garbage.
* fix out-of-bounds reads in __dns_parseAlexey Izbyshev2023-02-271-3/+3
| | | | | | | | | | | | | | | | | | | | | | | There are several issues with range checks in this function: * The question section parsing loop can read up to two out-of-bounds bytes before doing the range check and bailing out. * The answer section parsing loop, in addition to the same issue as above, uses the wrong length in the range check that doesn't prevent OOB reads when computing len later. * The len range check before calling the callback is off by 10. Also, p+len can overflow in a (probably theoretical) case when p is within 2^16 from UINTPTR_MAX. Because __dns_parse is used only with stack-allocated buffers, such small overreads can't result in a segfault. The first two also don't affect the function result, but the last one may result in getaddrinfo incorrectly succeeding and returning up to 10 bytes past the response buffer as a part of the IP address, and in (canon) name returned by getaddrinfo/getnameinfo being affected by memory past the response buffer (because dn_expand might interpret it as a pointer).
* fix incorrect unit for CPU_SETSIZE macroRich Felker2023-02-231-1/+1
| | | | | this macro is supposed to reflect the number of members (bits) in cpu_set_t, not the storage size (bytes).
* dns: prefer monotonic clock for timeoutsA. Wilcox2023-02-121-1/+2
| | | | | | | | | Before this commit, DNS timeouts always used CLOCK_REALTIME, which could produce spurious timeouts or delays if wall time changed for whatever reason. Now we try CLOCK_MONOTONIC and only fall back to CLOCK_REALTIME when it is unavailable.
* fix return value of wcs{,n}cmp for extreme wchar_t valuesGabriel Ravier2023-02-122-2/+2
| | | | | | | | | | | | | | As a result of using simple subtraction to implement the return values for wcscmp and wcsncmp, integer overflow can occur (producing undefined behavior, and in practice, a wrong comparison result). This does not occur for meaningful character values (21-bit range) but the functions are specified to work on arbitrary wchar_t arrays. This patch replaces the subtraction with a little bit of code that orders the characters correctly, returning -1 if the character from the first string is smaller than the one from the second, 0 if they are equal and 1 if the character from the first string is larger than the one from the second.
* math: fix undefined shift in logfSzabolcs Nagy2023-02-121-1/+1
| | | | | | | | A signed int shift overflowed when computing a constant mask, use hex literal instead. This is unlikely to cause actual issues unless the code was compiled with ubsan or similar instrumentation specifically to catch this. The stripped libc.so is unchanged on x86_64. Reported by q66 on irc.
* inet_pton: fix uninitialized memory use for IPv4-mapped IPv6 addressesAlexey Izbyshev2023-02-121-0/+1
| | | | | | | | | | | | | | When a dot is encountered, the loop counter is incremented before exiting the loop, but the corresponding ip array element is left uninitialized, so the subsequent memmove (if "::" was seen) and the loop copying ip to the output buffer will operate on an uninitialized uint16_t. The uninitialized data never directly influences the control flow and is overwritten on successful return by the second half of the parsed IPv4 address. But it's better to fix this to avoid unexpected transformations by a sufficiently smart compiler and reports from UB-detection tools.
* hsearch: fix null pointer arithmetic UBSzabolcs Nagy2023-02-121-2/+2
| | | | | htab->__tab->entries pointer may be 0 so delay using it in arithmetics. this did not cause any known issue other than with ubsan instrumentation.
* increase sendmsg internal buffer to support SCM_MAX_FDColin Cross2023-02-121-2/+5
| | | | | | | | | | | The kernel defines a limit on the number of fds that can be passed through an SCM_RIGHTS ancillary message as SCM_MAX_FD. The value was 255 before kernel 2.6.38 (after that it is 253), and an SCM_RIGHTS ancillary message with 255 fds requires 1040 bytes, slightly more than the current 1024 byte internal buffer in sendmsg. 1024 is an arbitrary size, so increase it to match the the arbitrary size limit in the kernel. This fixes tests that are verifying they support up to SCM_MAX_FD fds.
* mq_notify: block all (application) signals in the worker threadRich Felker2023-02-121-0/+5
| | | | | | | | | | | | | | | until the mq notification event arrives, it is mandatory that signals be blocked. otherwise, a signal can be received, and its handler executed, in a thread which does not yet exist on the abstract machine. after the point of the event arriving, having signals blocked is not a conformance requirement but a QoI requirement. while the application can unblock any signals it wants unblocked in the event handler thread, if they did not start out blocked, it could not block them without a race window where they are momentarily unblocked, and this would preclude controlled delivery or other forms of acceptance (sigwait, etc.) anywhere in the application.
* mq_notify: join worker thread before returning in error pathRich Felker2023-02-121-2/+5
| | | | | this avoids leaving behind transient resource consumption whose cleanup is subject to scheduling behavior.
* mq_notify: rework to fix use-after-close/double-close bugsRich Felker2023-02-121-8/+15
| | | | | | | | | | | | | in the error path where the mq_notify syscall fails, the initiating thread may have closed the socket before the worker thread calls recv on it. even in the absence of such a race, if the recv call failed, e.g. due to seccomp policy blocking it, the worker thread could proceed to close, producing a double-close condition. this can all be simplified by moving the mq_notify syscall into the new thread, so that the error case does not require pthread_cancel. now, the initiating thread only needs to read back the error status after waiting for the worker thread to consume its arguments.
* mq_notify: use semaphore instead of barrier to sync args consumptionRich Felker2023-02-111-5/+9
| | | | | semaphores are a much lighter primitive, and more idiomatic with current usage in the code base.
* fix pthread_detach inadvertently acting as cancellation point in race caseRich Felker2023-02-111-2/+6
| | | | | | | | disabling cancellation around the pthread_join call seems to be the safest and logically simplest fix. i believe it would also be possible to just perform the unmap directly here after __tl_sync, removing the dependency on pthread_join, but such an approach duplicately encodes a lot more implementation assumptions.
* powerpc-sf longjmp clobbering of val argumentRich Felker2023-02-111-4/+4
| | | | | | the logic to check hwcap for SPE register file inadvertently clobbered the val argument before use. switch to a different work register so this doesn't happen.
* riscv64: add vforkPedro Falcato2023-02-091-0/+12
| | | | Implement vfork() using clone(CLONE_VM | CLONE_VFORK | ...).
* fix wrong sigaction syscall ABI on mips*, or1k, microblaze, riscv64Rich Felker2023-02-0914-50/+12
| | | | | | | | | | | | | | | | | | | | | we wrongly defined a dummy SA_RESTORER flag on these archs, despite the kernel interface not actually having such a feature. on archs which lack SA_RESTORER, the kernel sigaction structure also lacks the restorer function pointer member, which means the signal mask appears at a different offset. the kernel was thereby interpreting the bits of the code address as part of the signal set to be masked while handling the signal. this patch removes the erroneous SA_RESTORER definitions from archs which do not have it, makes access to the member conditional on whether SA_RESTORER is defined for the arch, and removes the now-unused asm for the affected archs. because there are reportedly versions of qemu-user which also use the wrong ABI here, the old ksigaction struct size is preserved with an unused member at the end. this is harmless and mitigates the risk of such a bug turning into a buffer overflow onto the sigaction function's stack.
* fix integer overflow in WIFSTOPPED macroRich Felker2023-02-082-2/+2
| | | | | | | | | the result of the 0xffff mask with the exit status could have bit 15 set, in which case multiplying by 0x10001 overflows 32-bit signed int. making the multiply unsigned avoids the overflow. it also changes the sign extension behavior of the subsequent >> operation, but the affected bits are all unwanted anyway and all discarded by the cast to short.
* fix debugger tracking of shared libraries on mips with PIE main programRich Felker2023-01-185-0/+11
| | | | | | | | mips has its own mechanisms for DT_DEBUG because it makes _DYNAMIC read-only, and the original mechanism, DT_MIPS_RLD_MAP, was PIE-incompatible. DT_MIPS_RLD_MAP_REL was added to remedy this, but we never implemented support for it. add it now using the same idioms for mips-specific ldso logic.
* expose memmem under baseline POSIX feature profileRich Felker2023-01-061-1/+1
| | | | | | | memmem has been adopted for the next issue of POSIX (outcome of tracker item 1061). since mem* is in the reserved namespace for string.h it's already fully conforming to expose it by default, so just do so.
* use libc-internal malloc for pthread_atforkRich Felker2022-12-171-0/+5
| | | | | | | | | while no lock is held here making it a lock-order issue, replacement malloc is likely to want to use pthread_atfork, possibly making the call to malloc infinitely recursive. even if not, there is no reason to prefer an application-provided malloc here.
* prevent invalid reads of nl_arg in printf_coreMarkus Wichmann2022-12-141-6/+8
| | | | | | | | | | | | | | printf_core() runs twice, and during its first run, nl_arg is uninitialized and must not be read. It gets initialized at the end of the first run. Conversely, nl_type does not need to be set during the second run, as its useful life has ended at that point, since the only time it is read is during that exact same initialization. Therefore we can simply alternate the assignments. p and w do still need to get values assigned to them, since at least one line in the same if-statement depends on that, but they can be dummy values. arg does not need to be assigned, since in the first run, we encounter a continue statement before using the argument.
* elf.h: add ELFCOMPRESS_ZSTDFangrui Song2022-12-141-0/+1
|
* semaphores: fix missed wakes from ABA bug in waiter count logicRich Felker2022-12-134-12/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | because the has-waiters state in the semaphore value futex word is only representable when the value is zero (the special value -1 represents "0 with potential new waiters"), it's lost if intervening operations make the semaphore value positive again. this creates an ABA issue in sem_post, whereby the post uses a stale waiters count rather than re-evaluating it, skipping the futex wake if the stale count was zero. the fix here is based on a proposal by Alexey Izbyshev, with minor changes to eliminate costly new spurious wake syscalls. the basic idea is to replace the special value -1 with a sticky waiters bit (repurposing the sign bit) preserved under both wait and post. any post that takes place with the waiters bit set will perform a futex wake. to be useful, the waiters bit needs to be removable, and to remove it safely, we perform a broadcast wake instead of a normal single-task wake whenever removing the bit. this lets any un-accounted-for waiters wake and re-add the waiters bit if they still need it. there are multiple possible choices for when to perform this broadcast, but the optimal choice seems to be doing it whenever the observed waiters count is less than two (semantically, this means exactly one, but we might see a stale count of zero). in this case, the expected number of threads to be woken is one, with exactly the same cost as a non-broadcast wake.
* ldso: fix invalid early references to extern-linkage libc.page_sizeRich Felker2022-11-301-1/+8
| | | | | | | | | | | | | | | | | | | | | | | when PAGE_SIZE is not constant, internal/libc.h defines it to expand to libc.page_size. however, kernel_mapped_dso, reachable from stage 2 of the dynamic linker bootstrap (__dls2), needs PAGE_SIZE to interpret the relro range. at this point the libc object is both uninitialized and invalid to access according to our model for bootstrapping, which does not assume any external-linkage objects are accessible until stages 2b/3. in practice it likely worked because hidden visibility tends to behave like internal linkage, but this is not a property that the dynamic linker was designed to rely upon. this bug likely manifested as relro malfunction on archs with variable page size, due to incorrect mask when aligning the relro bounds to page boundaries. while there are certainly more direct ways to fix the known problem point here, a maximally future-proof way is to just bypass the libc.h PAGE_SIZE definition in the dynamic linker and instead have dynlink.c define its own internal-linkage object for variable page size. then, if anything else in stage 2 ever ends up referencing PAGE_SIZE, it will just automatically work right.
* pthread_atfork: fix return value on malloc failureAlexey Izbyshev2022-11-121-1/+2
| | | | | POSIX requires pthread_atfork to report errors via its return value, not via errno. The only specified error is ENOMEM.
* fix double-processing of DT_RELR relocations in ldso relocating itselfRich Felker2022-11-101-0/+1
| | | | | | this is analogous to skip_relative logic in do_relocs -- because relative relocations for the dynamic linker itself were already performed at entry (stage 1), they must not be applied again.
* fix strverscmp comparison of digit sequence with non-digitsRich Felker2022-11-071-3/+3
| | | | | | | | | | | | the rule that longest digit sequence not beginning with a zero is greater only applies when both sequences being compared are non-degenerate. this is spelled out explicitly in the man page, which may be deemed authoritative for this nonstandard function: "If one or both of these is empty, then return what strcmp(3) would have returned..." we were wrongly treating any sequence of digits not beginning with a zero as greater than a non-digit in the other string.
* fix async thread cancellation stack alignmentRich Felker2022-11-051-1/+6
| | | | | | | | | | | | | | | if async cancellation is enabled and acted upon, the stack pointer is not necessarily pointing to a __syscall_cp_asm stack frame. the contents of the stack being wrong don't really matter, but if the stack pointer is not suitably aligned, the procedure call ABI is violated when calling back into C code via __cancel, and pthread_exit, cancellation cleanup handlers, TSD destructors, etc. may malfunction or crash. for the async cancel case, just call __cancel directly like we did prior to commit 102f6a01e249ce4495f1119ae6d963a2a4a53ce5. restore the signal mask prior to doing this since the cancellation handler runs with all signals blocked.
* fix return value of gethostby{name[2],addr} with no result but no errorRich Felker2022-10-202-2/+2
| | | | | | | | | | | commit f081d5336a80b68d3e1bed789cc373c5c3d6699b fixed gethostbyname[2]_r to treat negative results as a non-error, leaving gethostbyname[2] wrongly returning a pointer to the unfilled result buffer rather than a null pointer. since, as documented with commit fe82bb9b921be34370e6b71a1c6f062c20999ae0, the caller of gethostby{name[2],addr}_r can always rely on the result pointer being set, use that consistently rather than trying to duplicate logic about whether we have a result or not in gethostby{name[2],addr}.
* clean up dns_parse_callbackRich Felker2022-10-191-13/+13
| | | | | | | | | | | | | the only functional change here should be that MAXADDRS is only checked for RRs that provide address results, so that a CNAME which appears after an excessive number of address RRs does not get ignored. I'm not aware of any servers that order the RRs this way, and it may even be forbidden to do so, but I prefer having the callback logic not be order dependent. other than that, the motivation for this change is that the A and AAAA cases were mostly duplicate code that could be combined as a single code path.
* dns response handling: don't treat too many addresses as an errorRich Felker2022-10-191-1/+1
| | | | | | | | | returning -1 rather than 0 from the parse function causes __dns_parse to bail out and return an error. presently, name_from_dns does not check the return value anyway, so this does not matter, but if it ever started treating this as an error, lookups with large numbers of addresses would break. this is a consequence of adding TCP support and extending the buffer size used in name_from_dns.
* dns response handling: ignore presence of wrong-type RRsRich Felker2022-10-191-2/+8
| | | | | | | | | | | | | | | | | | | | | | | reportedly there is nameserver software with question-rewriting "functionality" which gives A answers when AAAA is queried. since we made no effort to validate that the answer RR type actually corresponds to the question asked, it was possible (depending on flags, etc.) for these answers to leak through, which the caller might not be prepared for. indeed, our implementation of gethostbyname2_r makes an assumption that the resulting addresses are in the family requested, and will misinterpret the results if they don't. commit 45ca5d3fcb6f874bf5ba55d0e9651cef68515395 already noted in fixing CVE-2017-15650 that this could happen, but did nothing to validate that the RR type of the answer matches the question; it just enforced the limit on number of results to preclude overflow. presently, name_from_dns ignores the return value of __dns_parse, so it doesn't really matter whether we return 0 (ignoring the RR) or -1 (parse-ending error) upon encountering the mismatched RR. if that ever changes, though, ignoring irrelevant answer RRs sounds like the semantically correct thing to do, so for now let's return 0 from the callback when this happens.
* fix missing synchronization of pthread TSD keys with MT-forkRich Felker2022-10-193-0/+12
| | | | | | | | | | | commit 167390f05564e0a4d3fcb4329377fd7743267560 seems to have overlooked the presence of a lock here, probably because it was one of the exceptions not using LOCK() but a rwlock. as such, it can't be added to the generic table of locks to take, so add an explicit atfork function for the pthread keys table. the order it is called does not particularly matter since nothing else in libc but pthread_exit interacts with keys.
* fgets: avoid arithmetic overflow when n==INT_MIN is passedRich Felker2022-10-191-2/+3
| | | | | | | performing n-- is not a safe operation for arbitrary signed input n. only perform the decrement in the code path where the initial n is greater than 1, and adjust the condition in the n<=1 code path to compensate for it not having been decremented.
* fix AS-safety of close when aio is in use and fd map is expandedRich Felker2022-10-191-0/+6
| | | | | | | | | | | | the aio operations that lead to calling __aio_get_queue with the possibility to expand the fd map are not AS-safe, but if they are interrupted by a signal handler, the signal handler may call close, which is required to be AS-safe. due to __aio_get_queue taking the write lock without blocking signals, such a call to close from a signal handler could deadlock. change __aio_get_queue to block signals if it needs to obtain a write lock, and restore when finished.
* fix use of uninitialized dummy_fut in aio_suspendAlexey Izbyshev2022-10-191-1/+1
| | | | | | | aio_suspend waits on a dummy futex in the corner case when the array of requests contains NULL pointers only. But the value of this futex was left uninitialized, so if it happens to be non-zero, aio_suspend degrades to spinning instead of blocking.
* fix potential deadlock between multithreaded fork and aioRich Felker2022-10-193-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | as reported by Alexey Izbyshev, there is a lock order inversion deadlock between the malloc lock and aio maplock at MT-fork time: _Fork attempts to take the aio maplock while fork already has the malloc lock, but a concurrent aio operation holding the maplock may attempt to allocate memory. move the __aio_atfork calls in the parent from _Fork to fork, and reorder the lock before most other locks, since nothing else depends on aio(*). this leaves us with the possibility that the child will not be able to obtain the read lock, if _Fork is used directly and happens concurrent with an aio operation. however, in that case, the child context is an async signal context that cannot call any further aio functions, so all we need is to ensure that close does not attempt to perform any aio cancellation. this can be achieved just by nulling out the map pointer. (*) even if other functions call close, they will only need a read lock, not a write lock, and read locks being recursive ensures they can obtain it. moreover, the number of read references held is bounded by something like twice the number of live threads, meaning that the read lock count cannot saturate.
* fix potential unsynchronized access to killlock state at thread exitRich Felker2022-10-191-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | as reported by Alexey Izbyshev, when the second-to-last thread exits causing a return to single-threaded (no locks needed) state, it creates a situation where the last remaining thread may obtain the killlock that's already held by the exiting thread. this means it may erroneously use the tid of the exiting thread, and may corrupt the lock state due to double-unlock. commit 8d81ba8c0bc6fe31136cb15c9c82ef4c24965040, which (re)introduced the switch back to single-threaded state, documents the intent that the first lock after switching back should provide the necessary synchronization. this is correct, but only works if the switch back is made after there is no further need for synchronization with locks (other than the thread list lock, which can't be bypassed) held by the exiting thread. in order to hit the bug, the remaining thread must first take a different lock, causing it to perform an actual lock one last time, consume the need_locks==-1 state, and transition to need_locks==0. after that, the next attempt to lock the exiting thread's killlock will bypass locking. fix this by reordering the unlocking of killlock at thread exit time, along with changes to the state protected by it, to occur earlier, before the switch to single-threaded state. there are really no constraints on where it's done, except that it occur after there is no longer any possibility of application code executing in the exiting thread, so do it as early as possible.
* fix potential deadlock in dlerror buffer handling at thread exitRich Felker2022-10-193-19/+18
| | | | | | | | | | | | | | | | | | | | | | ever since commit 8f11e6127fe93093f81a52b15bb1537edc3fc8af introduced the thread list lock, this has been wrong. initially, it was wrong via calling free from the context with the thread list lock held. commit aa5a9d15e09851f7b4a1668e9dbde0f6234abada deferred the unsafe free but added a lock, which was also unsafe. in particular, it could deadlock if code holding freebuf_queue_lock was interrupted by a signal handler that takes the thread list lock. commit 4d5aa20a94a2d3fae3e69289dc23ecafbd0c16c4 observed that there was a lock here but failed to notice that it's invalid. there is no easy solution to this problem with locks; any attempt at solving it while still using locks would require the lock to be an AS-safe one (blocking signals on each access to the dlerror buffer list to check if there's deferred free work to be done) which would be excessively costly, and there are also lock order considerations with respect to how the lock would be handled at fork. instead, just use an atomic list.
* configure: disable TBAA optimization because most compilers are buggyRich Felker2022-10-191-0/+8
| | | | | | | | | | | | | | | | | | | | | | | unlike most projects that use -fno-strict-aliasing, we aim to have all sources respect the C language rules for effective type that make type-based alias analysis optimizations possible. unfortunately, it turns out that there are deep, and likely very difficult to fix, flaws in the TBAA performed by GCC and likely other compilers, whereby this kind of optimization can transform code that follows the rules strictly in ways that will make it malfunction. see for example GCC bugs 107107 and 107115, the latter of which also affects clang. there are not presently any known instances of breakage due to wrong type-based aliasing optimizations in our codebase. nonetheless, since the transformations are unsound and could introduce breakage, configure CFLAGS to build with -fno-strict-aliasing. some casual analysis of the effects on codegen suggest that this is unlikely to affect performance except possibly in the regex engine. in general, we should probably prefer making better use of the restrict keyword over relying on types to imply non-aliasing for optimization purposes; doing so should be able to get back any performance that was lost and more, should it turn out to matter (unlikely).
* disable MADV_FREE usage in mallocngRich Felker2022-10-192-1/+3
| | | | | | | | | | | | | | | | | | | | | | | the entire intent of using madvise/MADV_FREE on freed slots is to improve system performance by avoiding evicting cache of useful data, or swapping useless data to disk, by marking any whole pages in the freed slot as discardable by the kernel. in particular, unlike unmapping the memory or replacing it with a PROT_NONE region, use of MADV_FREE does not make any difference to memory accounting for commit charge purposes, and so does not increase the memory available to other processes in a non-overcommitted environment. however, various measurements have shown that inordinate amounts of time are spent performing madvise syscalls in processes which frequently allocate and free medium sized objects in the size range roughly between PAGESIZE and MMAP_THRESHOLD, to the point that the net effect is almost surely significant performance degredation. so, turn it off. the code, which has some nontrivial logic for efficiently determining whether there is a whole-page range to apply madvise to, is left in place so that it can easily be re-enabled if desired, or later tuned to only apply to certain sizes or to use additional heuristics.
* remove LFS64 programming interfaces (macro-only) from _GNU_SOURCERich Felker2022-10-1916-16/+16
| | | | | | | | | | | | | | | | | these badly pollute the namespace with macros whenever _GNU_SOURCE is defined, which is always the case with g++, and especially tends to interfere with C++ constructs. as our implementation of these was macro-only, their removal cannot affect any existing binaries. at the source level, portable software should be prepared for them not to exist. for now, they are left in place with explicit _LARGEFILE64_SOURCE. this provides an easy temporary path for integrators/distributions to get packages building again right away if they break while working on a proper, upstreamable fix. the intent is that this be a very short-term measure and that the macros be removed entirely in the next release cycle.
* remove LFS64 symbol aliases; replace with dynamic linker remappingRich Felker2022-10-1957-135/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | originally the namespace-infringing "large file support" interfaces were included as part of glibc-ABI-compat, with the intent that they not be used for linking, since our off_t is and always has been unconditionally 64-bit and since we usually do not aim to support nonstandard interfaces when there is an equivalent standard interface. unfortunately, having the symbols present and available for linking caused configure scripts to detect them and attempt to use them without declarations, producing all the expected ill effects that entails. as a result, commit 2dd8d5e1b8ba1118ff1782e96545cb8a2318592c was made to prevent this, using macros to redirect the LFS64 names to the standard names, conditional on _GNU_SOURCE or _LARGEFILE64_SOURCE. however, this has turned out to be a source of further problems, especially since g++ defines _GNU_SOURCE by default. in particular, the presence of these names as macros breaks a lot of valid code. this commit removes all the LFS64 symbols and replaces them with a mechanism in the dynamic linker symbol lookup failure path to retry with the spurious "64" removed from the symbol name. in the future, if/when the rest of glibc-ABI-compat is moved out of libc, this can be removed.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-16 08:37:23 +0000