about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
...
* aarch64: Optimize string functions with shrn instructionDanila Kutenin2024-04-096-102/+59
| | | | | | | | | | | | | | | We found that string functions were using AND+ADDP to find the nibble/syndrome mask but there is an easier opportunity through `SHRN dst.8b, src.8h, 4` (shift right every 2 bytes by 4 and narrow to 1 byte) and has same latency on all SIMD ARMv8 targets as ADDP. There are also possible gaps for memcmp but that's for another patch. We see 10-20% savings for small-mid size cases (<=128) which are primary cases for general workloads. (cherry picked from commit 3c9980698988ef64072f1fac339b180f52792faf)
* AArch64: Sort makefile entriesWilco Dijkstra2024-04-091-6/+18
| | | | | | Sort makefile entries to reduce conflicts. (cherry picked from commit eea282d9c665392d6959f6d7112ba4bef27701c9)
* AArch64: Add SVE memcpyWilco Dijkstra2024-04-095-42/+284
| | | | | | | | Add an initial SVE memcpy implementation. Copies up to 32 bytes use SVE vectors which improves the random memcpy benchmark significantly. Cleanup the memcpy and memmove ifunc selectors. (cherry picked from commit 9f298bfe1f183804bb54b54ff9071afc0494906c)
* AArch64: Optimize memcmpWilco Dijkstra2024-04-091-107/+134
| | | | | | | | | Rewrite memcmp to improve performance. On small and medium inputs performance is 10-20% better. Large inputs use a SIMD loop processing 64 bytes per iteration, which is 30-50% faster depending on the size. Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com> (cherry picked from commit b51eb35c572b015641f03e3682c303f7631279b7)
* Revert "elf: Fix wrong break removal from 8ee878592c"Adhemerval Zanella2024-02-121-1/+0
| | | | | | (2.34 does not have 8ee878592c) This reverts commit 62ac4b09c4ee66c91478212359b8ac44b4f6a9e2.
* malloc: Use __get_nprocs on arena_get2 (BZ 30945)Adhemerval Zanella2024-02-125-18/+2
| | | | | | | | | | | | | | | | | | This restore the 2.33 semantic for arena_get2. It was changed by 11a02b035b46 to avoid arena_get2 call malloc (back when __get_nproc was refactored to use an scratch_buffer - 903bc7dcc2acafc). The __get_nproc was refactored over then and now it also avoid to call malloc. The 11a02b035b46 did not take in consideration any performance implication, which should have been discussed properly. The __get_nprocs_sched is still used as a fallback mechanism if procfs and sysfs is not acessible. Checked on x86_64-linux-gnu. Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit 472894d2cfee5751b44c0aaa71ed87df81c8e62e)
* elf: Fix wrong break removal from 8ee878592cAdhemerval Zanella2024-02-051-0/+1
| | | | | Reported-by: Alexander Monakov <amonakov@ispras.ru> (cherry picked from commit 546a1ba664626603660b595662249d524e429013)
* x86_64: Optimize ffsll function code size.Sunil K Pandey2024-01-311-5/+5
| | | | | | | | | | | | | | | | | | Ffsll function randomly regress by ~20%, depending on how code gets aligned in memory. Ffsll function code size is 17 bytes. Since default function alignment is 16 bytes, it can load on 16, 32, 48 or 64 bytes aligned memory. When ffsll function load at 16, 32 or 64 bytes aligned memory, entire code fits in single 64 bytes cache line. When ffsll function load at 48 bytes aligned memory, it splits in two cache line, hence random regression. Ffsll function size reduction from 17 bytes to 12 bytes ensures that it will always fit in single 64 bytes cache line. This patch fixes ffsll function random performance regression. Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 9d94997b5f9445afd4f2bccc5fa60ff7c4361ec1)
* NEWS: Mention bug fixes for 29039/30745/30843H.J. Lu2023-12-231-0/+3
|
* x86-64: Fix the tcb field load for x32 [BZ #31185]H.J. Lu2023-12-232-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | _dl_tlsdesc_undefweak and _dl_tlsdesc_dynamic access the thread pointer via the tcb field in TCB: _dl_tlsdesc_undefweak: _CET_ENDBR movq 8(%rax), %rax subq %fs:0, %rax ret _dl_tlsdesc_dynamic: ... subq %fs:0, %rax movq -8(%rsp), %rdi ret Since the tcb field in TCB is a pointer, %fs:0 is a 32-bit location, not 64-bit. It should use "sub %fs:0, %RAX_LP" instead. Since _dl_tlsdesc_undefweak returns ptrdiff_t and _dl_make_tlsdesc_dynamic returns void *, RAX_LP is appropriate here for x32 and x86-64. This fixes BZ #31185. (cherry picked from commit 81be2a61dafc168327c1639e97b6dae128c7ccf3)
* x86-64: Fix the dtv field load for x32 [BZ #31184]H.J. Lu2023-12-232-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On x32, I got FAIL: elf/tst-tlsgap $ gdb elf/tst-tlsgap ... open tst-tlsgap-mod1.so Thread 2 "tst-tlsgap" received signal SIGSEGV, Segmentation fault. [Switching to LWP 2268754] _dl_tlsdesc_dynamic () at ../sysdeps/x86_64/dl-tlsdesc.S:108 108 movq (%rsi), %rax (gdb) p/x $rsi $4 = 0xf7dbf9005655fb18 (gdb) This is caused by _dl_tlsdesc_dynamic: _CET_ENDBR /* Preserve call-clobbered registers that we modify. We need two scratch regs anyway. */ movq %rsi, -16(%rsp) movq %fs:DTV_OFFSET, %rsi Since the dtv field in TCB is a pointer, %fs:DTV_OFFSET is a 32-bit location, not 64-bit. Load the dtv field to RSI_LP instead of rsi. This fixes BZ #31184. (cherry picked from commit 3502440397bbb840e2f7223734aa5cc2cc0e29b6)
* elf: Fix TLS modid reuse generation assignment (BZ 29039)Hector Martin2023-12-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _dl_assign_tls_modid() assigns a slotinfo entry for a new module, but does *not* do anything to the generation counter. The first time this happens, the generation is zero and map_generation() returns the current generation to be used during relocation processing. However, if a slotinfo entry is later reused, it will already have a generation assigned. If this generation has fallen behind the current global max generation, then this causes an obsolete generation to be assigned during relocation processing, as map_generation() returns this generation if nonzero. _dl_add_to_slotinfo() eventually resets the generation, but by then it is too late. This causes DTV updates to be skipped, leading to NULL or broken TLS slot pointers and segfaults. Fix this by resetting the generation to zero in _dl_assign_tls_modid(), so it behaves the same as the first time a slot is assigned. _dl_add_to_slotinfo() will still assign the correct static generation later during module load, but relocation processing will no longer use an obsolete generation. Note that slotinfo entry (aka modid) reuse typically happens after a dlclose and only TLS access via dynamic tlsdesc is affected. Because tlsdesc is optimized to use the optional part of static TLS, dynamic tlsdesc can be avoided by increasing the glibc.rtld.optional_static_tls tunable to a large enough value, or by LD_PRELOAD-ing the affected modules. Fixes bug 29039. Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com> (cherry picked from commit 3921c5b40f293c57cb326f58713c924b0662ef59)
* tunables: Terminate if end of input is reached (CVE-2023-4911)Siddhesh Poyarekar2023-10-023-15/+44
| | | | | | | | | | | | | | | | | | The string parsing routine may end up writing beyond bounds of tunestr if the input tunable string is malformed, of the form name=name=val. This gets processed twice, first as name=name=val and next as name=val, resulting in tunestr being name=name=val:name=val, thus overflowing tunestr. Terminate the parsing loop at the first instance itself so that tunestr does not overflow. This also fixes up tst-env-setuid-tunables to actually handle failures correct and add new tests to validate the fix for this CVE. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 1056e5b4c3f2d90ed2b4a55f96add28da2f4c8fa)
* Document CVE-2023-4806 and CVE-2023-5156 in NEWSSiddhesh Poyarekar2023-09-261-0/+9
| | | | | | | These are tracked in BZ #30884 and BZ #30843. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit fd134feba35fa839018965733b34d28a09a075dd)
* Fix leak in getaddrinfo introduced by the fix for CVE-2023-4806 [BZ #30843]Romain Geissler2023-09-263-3/+24
| | | | | | | | | | | | This patch fixes a very recently added leak in getaddrinfo. This was assigned CVE-2023-5156. Resolves: BZ #30884 Related: BZ #30842 Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit ec6b95c3303c700eb89eebeda2d7264cc184a796)
* getaddrinfo: Fix use after free in getcanonname (CVE-2023-4806)Siddhesh Poyarekar2023-09-157-10/+151
| | | | | | | | | | | | | | | | | | | | | | | | When an NSS plugin only implements the _gethostbyname2_r and _getcanonname_r callbacks, getaddrinfo could use memory that was freed during tmpbuf resizing, through h_name in a previous query response. The backing store for res->at->name when doing a query with gethostbyname3_r or gethostbyname2_r is tmpbuf, which is reallocated in gethosts during the query. For AF_INET6 lookup with AI_ALL | AI_V4MAPPED, gethosts gets called twice, once for a v6 lookup and second for a v4 lookup. In this case, if the first call reallocates tmpbuf enough number of times, resulting in a malloc, th->h_name (that res->at->name refers to) ends up on a heap allocated storage in tmpbuf. Now if the second call to gethosts also causes the plugin callback to return NSS_STATUS_TRYAGAIN, tmpbuf will get freed, resulting in a UAF reference in res->at->name. This then gets dereferenced in the getcanonname_r plugin call, resulting in the use after free. Fix this by copying h_name over and freeing it at the end. This resolves BZ #30843, which is assigned CVE-2023-4806. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit 973fe93a5675c42798b2161c6f29c01b0e243994)
* gethosts: Return EAI_MEMORY on allocation failureSiddhesh Poyarekar2023-09-151-2/+2
| | | | | | | | | | All other cases of failures due to lack of memory return EAI_MEMORY, so it seems wrong to return EAI_SYSTEM here. The only reason convert_hostent_to_gaih_addrtuple could fail is on calloc failure. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit b587456c0e7b59dcfdbd2d44db000a3bc8244e57)
* gaih_inet: Split result generation into its own functionSiddhesh Poyarekar2023-09-151-90/+86
| | | | | | | | Simplify the loop a wee bit and clean up variable names too. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit ac4653ef503d1e87893d1a6714748a1cdf4bf7ad)
* gaih_inet: split loopback lookup into its own functionSiddhesh Poyarekar2023-09-151-65/+62
| | | | | | | | | | | | | Flatten the condition nesting and replace the alloca for RET.AT/ATR with a single array LOCAL_AT[2]. This gets rid of alloca and alloca accounting. `git diff -b` is probably the best way to view this change since much of the diff is whitespace changes. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit 657472b2a50f67b12e5bbe5827582c9c2bb82dc3)
* gaih_inet: make gethosts into a functionSiddhesh Poyarekar2023-09-151-58/+59
| | | | | | | | | The macro is quite a pain to debug, so make gethosts into a function to make it easier to maintain. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit cfa3bd48cb19a70e4367a9978dbba09d9df27a72)
* gaih_inet: separate nss lookup loop into its own functionSiddhesh Poyarekar2023-09-151-277/+286
| | | | | | Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit 906cecbe0889e601c91d9aba738049c73ebe4dd2)
* gaih_inet: Split nscd lookup code into its own function.Siddhesh Poyarekar2023-09-151-114/+134
| | | | | | | | | Add a new member got_ipv6 to indicate if the results have an IPv6 result and use it instead of the local got_ipv6. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit e7e5315b7fa065a9c8bf525ca9a32f46fa4837e5)
* gaih_inet: Split simple gethostbyname into its own functionSiddhesh Poyarekar2023-09-151-63/+64
| | | | | | | | | Add a free_at flag in gaih_result to indicate if res.at needs to be freed by the caller. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit b44389cb7fa28a59804571dac09cc32ebfac03d1)
* gaih_inet: make numeric lookup a separate routineSiddhesh Poyarekar2023-09-151-439/+452
| | | | | | | | | | | | | | Introduce the gaih_result structure and general paradigm for cleanups that follow to process the lookup request and return a result. A lookup function (like text_to_binary_address), should return an integer error code and set members of gaih_result based on what it finds. If the function does not have a result and no errors have occurred during the lookup, it should return 0 and res.at should be set to NULL, allowing a subsequent function to do the lookup until we run out of options. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit 26dea461191cca519b498890a9682fe4bc8e4c2f)
* gaih_inet: Simplify service resolutionSiddhesh Poyarekar2023-09-151-100/+78
| | | | | | | | | | | Refactor the code to split out the service resolution code into a separate function. Allocate the service tuples array just once to the size of the typeproto array, thus avoiding the unnecessary pointer chasing and stack allocations. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit 8d6cf99f2fb81a097f9334c125e5c23604af1a98)
* getaddrinfo: Fix leak with AI_ALL [BZ #28852]Siddhesh Poyarekar2023-09-151-9/+25
| | | | | | | | | | | | | | Use realloc in convert_hostent_to_gaih_addrtuple and fix up pointers in the result list so that a single block is maintained for hostbyname3_r/hostbyname2_r and freed in gaih_inet. This result is never merged with any other results, since the hosts database does not permit merging. Resolves BZ #28852. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit 300460460706ce3ffe29a7df8966e68323ec5bf1)
* gaih_inet: Simplify canon name resolutionSiddhesh Poyarekar2023-09-151-55/+75
| | | | | | | | | | Simplify logic for allocation of canon to remove the canonbuf variable; canon now always points to an allocated block. Also pull the canon name set into a separate function. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit d01411f6bc61429fc027c38827bf3103b48eef2e)
* gethosts: Remove unused argument _typeSiddhesh Poyarekar2023-09-151-3/+3
| | | | | | The generated code is unchanged. (cherry picked from commit b17e842a60819098d2a203ecc8b8371b7e1d6c65)
* nss: Sort tests and tests-container and put one test per lineSiddhesh Poyarekar2023-09-151-16/+25
| | | | | Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit e2f68b54e8052da14680074fc5df03153216f218)
* Simplify allocations and fix merge and continue actions [BZ #28931]Siddhesh Poyarekar2023-09-145-53/+751
| | | | | | | | | | | | | | | | | | | | | | Allocations for address tuples is currently a bit confusing because of the pointer chasing through PAT, making it hard to observe the sequence in which allocations have been made. Narrow scope of the pointer chasing through PAT so that it is only used where necessary. This also tightens actions behaviour with the hosts database in getaddrinfo to comply with the manual text. The "continue" action discards previous results and the "merge" action results in an immedate lookup failure. Consequently, chaining of allocations across modules is no longer necessary, thus opening up cleanup opportunities. A test has been added that checks some combinations to ensure that they work correctly. Resolves: BZ #28931 Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit 1c37b8022e8763fedbb3f79c02e05c6acfe5a215)
* x86: Fix incorrect scope of setting `shared_per_thread` [BZ# 30745]Noah Goldstein2023-09-051-4/+3
| | | | | | | | | | | | | | | | The: ``` if (shared_per_thread > 0 && threads > 0) shared_per_thread /= threads; ``` Code was accidentally moved to inside the else scope. This doesn't match how it was previously (before af992e7abd). This patch fixes that by putting the division after the `else` block. (cherry picked from commit 084fb31bc2c5f95ae0b9e6df4d3cf0ff43471ede)
* x86: Use `3/4*sizeof(per-thread-L3)` as low bound for NT threshold.Noah Goldstein2023-09-051-1/+10
| | | | | | | | | | | On some machines we end up with incomplete cache information. This can make the new calculation of `sizeof(total-L3)/custom-divisor` end up lower than intended (and lower than the prior value). So reintroduce the old bound as a lower bound to avoid potentially regressing code where we don't have complete information to make the decision. Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit 8b9a0af8ca012217bf90d1dc0694f85b49ae09da)
* x86: Fix slight bug in `shared_per_thread` cache size calculation.Noah Goldstein2023-09-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | After: ``` commit af992e7abdc9049714da76cae1e5e18bc4838fb8 Author: Noah Goldstein <goldstein.w.n@gmail.com> Date: Wed Jun 7 13:18:01 2023 -0500 x86: Increase `non_temporal_threshold` to roughly `sizeof_L3 / 4` ``` Split `shared` (cumulative cache size) from `shared_per_thread` (cache size per socket), the `shared_per_thread` *can* be slightly off from the previous calculation. Previously we added `core` even if `threads_l2` was invalid, and only used `threads_l2` to divide `core` if it was present. The changed version only included `core` if `threads_l2` was valid. This change restores the old behavior if `threads_l2` is invalid by adding the entire value of `core`. Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit 47f747217811db35854ea06741be3685e8bbd44d)
* x86: Increase `non_temporal_threshold` to roughly `sizeof_L3 / 4`Noah Goldstein2023-09-051-31/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current `non_temporal_threshold` set to roughly '3/4 * sizeof_L3 / ncores_per_socket'. This patch updates that value to roughly 'sizeof_L3 / 4` The original value (specifically dividing the `ncores_per_socket`) was done to limit the amount of other threads' data a `memcpy`/`memset` could evict. Dividing by 'ncores_per_socket', however leads to exceedingly low non-temporal thresholds and leads to using non-temporal stores in cases where REP MOVSB is multiple times faster. Furthermore, non-temporal stores are written directly to main memory so using it at a size much smaller than L3 can place soon to be accessed data much further away than it otherwise could be. As well, modern machines are able to detect streaming patterns (especially if REP MOVSB is used) and provide LRU hints to the memory subsystem. This in affect caps the total amount of eviction at 1/cache_associativity, far below meaningfully thrashing the entire cache. As best I can tell, the benchmarks that lead this small threshold where done comparing non-temporal stores versus standard cacheable stores. A better comparison (linked below) is to be REP MOVSB which, on the measure systems, is nearly 2x faster than non-temporal stores at the low-end of the previous threshold, and within 10% for over 100MB copies (well past even the current threshold). In cases with a low number of threads competing for bandwidth, REP MOVSB is ~2x faster up to `sizeof_L3`. The divisor of `4` is a somewhat arbitrary value. From benchmarks it seems Skylake and Icelake both prefer a divisor of `2`, but older CPUs such as Broadwell prefer something closer to `8`. This patch is meant to be followed up by another one to make the divisor cpu-specific, but in the meantime (and for easier backporting), this patch settles on `4` as a middle-ground. Benchmarks comparing non-temporal stores, REP MOVSB, and cacheable stores where done using: https://github.com/goldsteinn/memcpy-nt-benchmarks Sheets results (also available in pdf on the github): https://docs.google.com/spreadsheets/d/e/2PACX-1vS183r0rW_jRX6tG_E90m9qVuFiMbRIJvi5VAE8yYOvEOIEEc3aSNuEsrFbuXw5c3nGboxMmrupZD7K/pubhtml Reviewed-by: DJ Delorie <dj@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit af992e7abdc9049714da76cae1e5e18bc4838fb8)
* debug: Mark libSegFault.so as NODELETEFlorian Weimer2023-07-211-0/+2
| | | | | | | | | The signal handler installed in the ELF constructor cannot easily be removed again (because the program may have changed handlers in the meantime). Mark the object as NODELETE so that the registered handler function is never unloaded. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Document BZ #20975 fixH.J. Lu2023-05-231-0/+1
|
* __check_pf: Add a cancellation cleanup handler [BZ #20975]H.J. Lu2023-05-232-0/+17
| | | | | | | | | | | | | | | | | | | | | | There are reports for hang in __check_pf: https://github.com/JoeDog/siege/issues/4 It is reproducible only under specific configurations: 1. Large number of cores (>= 64) and large number of threads (> 3X of the number of cores) with long lived socket connection. 2. Low power (frequency) mode. 3. Power management is enabled. While holding lock, __check_pf calls make_request which calls __sendto and __recvmsg. Since __sendto and __recvmsg are cancellation points, lock held by __check_pf won't be released and can cause deadlock when thread cancellation happens in __sendto or __recvmsg. Add a cancellation cleanup handler for __check_pf to unlock the lock when cancelled by another thread. This fixes BZ #20975 and the siege hang issue. (cherry picked from commit a443bd3fb233186038b8b483959ecb7978d1abea)
* gmon: Revert addition of tunables to preserve GLIBC_PRIVATE ABIFlorian Weimer2023-04-283-88/+1
| | | | | | | | Otherwise, processes are likely to crash during concurrent updates to a new glibc version on the stable release branch. The test gmon/tst-mcount-overflow depends on those tunables, so it has to be removed as well.
* gmon: fix memory corruption issues [BZ# 30101]Simon Kissane2023-04-284-9/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V2 of this patch fixes an issue in V1, where the state was changed to ON not OFF at end of _mcleanup. I hadn't noticed that (counterintuitively) ON=0 and OFF=3, hence zeroing the buffer turned it back on. So set the state to OFF after the memset. 1. Prevent double free, and reads from unallocated memory, when _mcleanup is (incorrectly) called two or more times in a row, without an intervening call to __monstartup; with this patch, the second and subsequent calls effectively become no-ops instead. While setting tos=NULL is minimal fix, safest action is to zero the whole gmonparam buffer. 2. Prevent memory leak when __monstartup is (incorrectly) called two or more times in a row, without an intervening call to _mcleanup; with this patch, the second and subsequent calls effectively become no-ops instead. 3. After _mcleanup, treat __moncontrol(1) as __moncontrol(0) instead. With zeroing of gmonparam buffer in _mcleanup, this stops the state incorrectly being changed to GMON_PROF_ON despite profiling actually being off. If we'd just done the minimal fix to _mcleanup of setting tos=NULL, there is risk of far worse memory corruption: kcount would point to deallocated memory, and the __profil syscall would make the kernel write profiling data into that memory, which could have since been reallocated to something unrelated. 4. Ensure __moncontrol(0) still turns off profiling even in error state. Otherwise, if mcount overflows and sets state to GMON_PROF_ERROR, when _mcleanup calls __moncontrol(0), the __profil syscall to disable profiling will not be invoked. _mcleanup will free the buffer, but the kernel will still be writing profiling data into it, potentially corrupted arbitrary memory. Also adds a test case for (1). Issues (2)-(4) are not feasible to test. Signed-off-by: Simon Kissane <skissane@gmail.com> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit bde121872001d8f3224eeafa5b7effb871c3fbca)
* gmon: improve mcount overflow handling [BZ# 27576]Simon Kissane2023-04-289-7/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When mcount overflows, no gmon.out file is generated, but no message is printed to the user, leaving the user with no idea why, and thinking maybe there is some bug - which is how BZ 27576 ended up being logged. Print a message to stderr in this case so the user knows what is going on. As a comment in sys/gmon.h acknowledges, the hardcoded MAXARCS value is too small for some large applications, including the test case in that BZ. Rather than increase it, add tunables to enable MINARCS and MAXARCS to be overridden at runtime (glibc.gmon.minarcs and glibc.gmon.maxarcs). So if a user gets the mcount overflow error, they can try increasing maxarcs (they might need to increase minarcs too if the heuristic is wrong in their case.) Note setting minarcs/maxarcs too large can cause monstartup to fail with an out of memory error. If you set them large enough, it can cause an integer overflow in calculating the buffer size. I haven't done anything to defend against that - it would not generally be a security vulnerability, since these tunables will be ignored in suid/sgid programs (due to the SXID_ERASE default), and if you can set GLIBC_TUNABLES in the environment of a process, you can take it over anyway (LD_PRELOAD, LD_LIBRARY_PATH, etc). I thought about modifying the code of monstartup to defend against integer overflows, but doing so is complicated, and I realise the existing code is susceptible to them even prior to this change (e.g. try passing a pathologically large highpc argument to monstartup), so I decided just to leave that possibility in-place. Add a test case which demonstrates mcount overflow and the tunables. Document the new tunables in the manual. Signed-off-by: Simon Kissane <skissane@gmail.com> Reviewed-by: DJ Delorie <dj@redhat.com> (cherry picked from commit 31be941e4367c001b2009308839db5c67bf9dcbc)
* gmon: Fix allocated buffer overflow (bug 29444)Леонид Юрьев (Leonid Yuriev)2023-04-282-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `__monstartup()` allocates a buffer used to store all the data accumulated by the monitor. The size of this buffer depends on the size of the internal structures used and the address range for which the monitor is activated, as well as on the maximum density of call instructions and/or callable functions that could be potentially on a segment of executable code. In particular a hash table of arcs is placed at the end of this buffer. The size of this hash table is calculated in bytes as p->fromssize = p->textsize / HASHFRACTION; but actually should be p->fromssize = ROUNDUP(p->textsize / HASHFRACTION, sizeof(*p->froms)); This results in writing beyond the end of the allocated buffer when an added arc corresponds to a call near from the end of the monitored address range, since `_mcount()` check the incoming caller address for monitored range but not the intermediate result hash-like index that uses to write into the table. It should be noted that when the results are output to `gmon.out`, the table is read to the last element calculated from the allocated size in bytes, so the arcs stored outside the buffer boundary did not fall into `gprof` for analysis. Thus this "feature" help me to found this bug during working with https://sourceware.org/bugzilla/show_bug.cgi?id=29438 Just in case, I will explicitly note that the problem breaks the `make test t=gmon/tst-gmon-dso` added for Bug 29438. There, the arc of the `f3()` call disappears from the output, since in the DSO case, the call to `f3` is located close to the end of the monitored range. Signed-off-by: Леонид Юрьев (Leonid Yuriev) <leo@yuriev.ru> Another minor error seems a related typo in the calculation of `kcountsize`, but since kcounts are smaller than froms, this is actually to align the p->froms data. Co-authored-by: DJ Delorie <dj@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 801af9fafd4689337ebf27260aa115335a0cb2bc)
* posix: Fix system blocks SIGCHLD erroneously [BZ #30163]Adam Yi2023-04-288-3/+141
| | | | | | | | | | | | | | | | | | | | | | Fix bug that SIGCHLD is erroneously blocked forever in the following scenario: 1. Thread A calls system but hasn't returned yet 2. Thread B calls another system but returns SIGCHLD would be blocked forever in thread B after its system() returns, even after the system() in thread A returns. Although POSIX does not require, glibc system implementation aims to be thread and cancellation safe. This bug was introduced in 5fb7fc96350575c9adb1316833e48ca11553be49 when we moved reverting signal mask to happen when the last concurrently running system returns, despite that signal mask is per thread. This commit reverts this logic and adds a test. Signed-off-by: Adam Yi <ayi@janestreet.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit 436a604b7dc741fc76b5a6704c6cd8bb178518e7)
* x86_64: Fix asm constraints in feraiseexcept (bug 30305)Florian Weimer2023-04-242-2/+3
| | | | | | | | | | The divss instruction clobbers its first argument, and the constraints need to reflect that. Fortunately, with GCC 12, generated code does not actually change, so there is no externally visible bug. Suggested-by: Jakub Jelinek <jakub@redhat.com> Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> (cherry picked from commit 5d1ccdda7b0c625751661d50977f3dfbc73f8eae)
* gshadow: Matching sgetsgent, sgetsgent_r ERANGE handling (bug 30151)Florian Weimer2023-04-244-2/+75
| | | | | | | | | | | | | | Before this change, sgetsgent_r did not set errno to ERANGE, but sgetsgent only check errno, not the return value from sgetsgent_r. Consequently, sgetsgent did not detect any error, and reported success to the caller, without initializing the struct sgrp object whose address was returned. This commit changes sgetsgent_r to set errno as well. This avoids similar issues in applications which only change errno. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit 969e9733c7d17edf1e239a73fa172f357561f440)
* x86: Check minimum/maximum of non_temporal_threshold [BZ #29953]H.J. Lu2023-04-202-9/+17
| | | | | | | | | | | The minimum non_temporal_threshold is 0x4040. non_temporal_threshold may be set to less than the minimum value when the shared cache size isn't available (e.g., in an emulator) or by the tunable. Add checks for minimum and maximum of non_temporal_threshold. This fixes BZ #29953. (cherry picked from commit 48b74865c63840b288bd85b4d8743533b73b339b)
* stdlib: Undo post review change to 16adc58e73f3 [BZ #27749]Vitaly Buka2023-02-203-2/+81
| | | | | | | | | | | Post review removal of "goto restart" from https://sourceware.org/pipermail/libc-alpha/2021-April/125470.html introduced a bug when some atexit handers skipped. Signed-off-by: Vitaly Buka <vitalybuka@google.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit fd78cfa72ea2bab30fdb4e1e0672b34471426c05)
* elf: Smoke-test ldconfig -p against system /etc/ld.so.cacheFlorian Weimer2023-02-082-0/+83
| | | | | | | | | The test is sufficient to detect the ldconfig bug fixed in commit 9fe6f6363886aae6b2b210cae3ed1f5921299083 ("elf: Fix 64 time_t support for installed statically binaries"). Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 9fd63e35371b9939e9153907c6a753e6960b68ad)
* elf: Fix 64 time_t support for installed statically binariesAdhemerval Zanella2023-02-086-39/+39
| | | | | | | | | | | | | | | The usage of internal static symbol for statically linked binaries does not work correctly for objects built with -D_TIME_BITS=64, since the internal definition does not provide the expected aliases. This patch makes it to use the default stat functions instead (which uses the default 64 time_t alias and types). Checked on i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 9fe6f6363886aae6b2b210cae3ed1f5921299083)
* Fix NEWS bug entry for 0b962177ee3b45cf775176eb454fcf6aa1b0f6e3Adhemerval Zanella2023-02-071-2/+1
|
* Use 64-bit time_t interfaces in strftime and strptime (bug 30053)Andreas Schwab2023-02-076-2/+64
| | | | | | Both functions use time_t only internally, so the ABI is not affected. (cherry picked from commit 41349f6f67c83e7bafe49f985b56493d2c4c9c77)
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-25 00:02:38 +0000