about summary refs log tree commit diff
path: root/sysdeps
Commit message (Collapse)AuthorAgeFilesLines
...
* 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)
* io: Fix F_GETLK, F_SETLK, and F_SETLKW for powerpc64Adhemerval Zanella2023-05-311-0/+6
| | | | | | | | | | | | | | | | | | | | Different than other 64 bit architectures, powerpc64 defines the LFS POSIX lock constants with values similar to 32 ABI, which are meant to be used with fcntl64 syscall. Since powerpc64 kABI does not have fcntl, the constants are adjusted with the FCNTL_ADJUST_CMD macro. The 4d0fe291aed3a476a changed the logic of generic constants LFS value are equal to the default values; which is now wrong for powerpc64. Fix the value by explicit define the previous glibc constants (powerpc64 does not need to use the 32 kABI value, but it simplifies the FCNTL_ADJUST_CMD which should be kept as compatibility). Checked on powerpc64-linux-gnu and powerpc-linux-gnu. (cherry picked from commit 5f828ff824e3b7cd133ef905b8ae25ab8a8f3d66)
* io: Fix record locking contants on 32 bit arch with 64 bit default time_t ↵Adhemerval Zanella2023-05-301-1/+1
| | | | | | | | | | | | | | | | | | | (BZ#30477) For architecture with default 64 bit time_t support, the kernel does not provide LFS and non-LFS values for F_GETLK, F_GETLK, and F_GETLK (the default value used for 64 bit architecture are used). This is might be considered an ABI break, but the currenct exported values is bogus anyway. The POSIX lockf is not affected since it is aliased to lockf64, which already uses the LFS values. Checked on i686-linux-gnu and the new tests on a riscv32. Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 4d0fe291aed3a476a3b59c4ecfae9d35ac0f15e8)
* __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)
* posix: Fix system blocks SIGCHLD erroneously [BZ #30163]Adam Yi2023-04-281-3/+3
| | | | | | | | | | | | | | | | | | | | | | 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-241-2/+2
| | | | | | | | | | 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)
* x86: Check minimum/maximum of non_temporal_threshold [BZ #29953]H.J. Lu2023-03-151-9/+16
| | | | | | | | | | | 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)
* x86: Prevent SIGSEGV in memcmp-sse2 when data is concurrently modified [BZ ↵Noah Goldstein2023-01-111-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | #29863] In the case of INCORRECT usage of `memcmp(a, b, N)` where `a` and `b` are concurrently modified as `memcmp` runs, there can be a SIGSEGV in `L(ret_nonzero_vec_end_0)` because the sequential logic assumes that `(rdx - 32 + rax)` is a positive 32-bit integer. To be clear, this change does not mean the usage of `memcmp` is supported. The program behaviour is undefined (UB) in the presence of data races, and `memcmp` is incorrect when the values of `a` and/or `b` are modified concurrently (data race). This UB may manifest itself as a SIGSEGV. That being said, if we can allow the idiomatic use cases, like those in yottadb with opportunistic concurrency control (OCC), to execute without a SIGSEGV, at no cost to regular use cases, then we can aim to minimize harm to those existing users. The fix replaces a 32-bit `addl %edx, %eax` with the 64-bit variant `addq %rdx, %rax`. The 1-extra byte of code size from using the 64-bit instruction doesn't contribute to overall code size as the next target is aligned and has multiple bytes of `nop` padding before it. As well all the logic between the add and `ret` still fits in the same fetch block, so the cost of this change is basically zero. The relevant sequential logic can be seen in the following pseudo-code: ``` /* * rsi = a * rdi = b * rdx = len - 32 */ /* cmp a[0:15] and b[0:15]. Since length is known to be [17, 32] in this case, this check is also assumed to cover a[0:(31 - len)] and b[0:(31 - len)]. */ movups (%rsi), %xmm0 movups (%rdi), %xmm1 PCMPEQ %xmm0, %xmm1 pmovmskb %xmm1, %eax subl %ecx, %eax jnz L(END_NEQ) /* cmp a[len-16:len-1] and b[len-16:len-1]. */ movups 16(%rsi, %rdx), %xmm0 movups 16(%rdi, %rdx), %xmm1 PCMPEQ %xmm0, %xmm1 pmovmskb %xmm1, %eax subl %ecx, %eax jnz L(END_NEQ2) ret L(END2): /* Position first mismatch. */ bsfl %eax, %eax /* The sequential version is able to assume this value is a positive 32-bit value because the first check included bytes in range a[0:(31 - len)] and b[0:(31 - len)] so `eax` must be greater than `31 - len` so the minimum value of `edx` + `eax` is `(len - 32) + (32 - len) >= 0`. In the concurrent case, however, `a` or `b` could have been changed so a mismatch in `eax` less or equal than `(31 - len)` is possible (the new low bound is `(16 - len)`. This can result in a negative 32-bit signed integer, which when zero extended to 64-bits is a random large value this out out of bounds. */ addl %edx, %eax /* Crash here because 32-bit negative number in `eax` zero extends to out of bounds 64-bit offset. */ movzbl 16(%rdi, %rax), %ecx movzbl 16(%rsi, %rax), %eax ``` This fix is quite simple, just make the `addl %edx, %eax` 64 bit (i.e `addq %rdx, %rax`). This prevents the 32-bit zero extension and since `eax` is still a low bound of `16 - len` the `rdx + rax` is bound by `(len - 32) - (16 - len) >= -16`. Since we have a fixed offset of `16` in the memory access this must be in bounds. (cherry picked from commit b712be52645282c706a5faa038242504feb06db5)
* elf/tst-tlsopt-powerpc fails when compiled with -mcpu=power10 (BZ# 29776)Alan Modra2023-01-101-1/+5
| | | | | | | Supports pcrel addressing of TLS GOT entry. Also tweak the non-pcrel asm constraint to better reflect how the reg is used. (cherry picked from commit 94628de77888c3292fc103840731ff85f283368e)
* x86: Fix -Os build (BZ #29576)Adhemerval Zanella Netto2022-12-281-0/+18
| | | | | | | | | | | | | The compiler might transform __stpcpy calls (which are routed to __builtin_stpcpy as an optimization) to strcpy and x86_64 strcpy multiarch implementation does not build any working symbol due ISA_SHOULD_BUILD not being evaluated for IS_IN(rtld). Checked on x86_64-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit 9dc4e29f630c6ef8299120b275e503321dc0c8c7)
* x86: Fix wcsnlen-avx2 page cross length comparison [BZ #29591]Noah Goldstein2022-11-241-5/+2
| | | | | | | | | | | | | Previous implementation was adjusting length (rsi) to match bytes (eax), but since there is no bound to length this can cause overflow. Fix is to just convert the byte-count (eax) to length by dividing by sizeof (wchar_t) before the comparison. Full check passes on x86-64 and build succeeds w/ and w/o multiarch. (cherry picked from commit b0969fa53a28b4ab2159806bf6c99a98999502ee)
* elf: Fix rtld-audit trampoline for aarch64Vladislav Khmelevsky2022-11-221-3/+1
| | | | | | | | | | | | | | | | This patch fixes two problems with audit: 1. The DL_OFFSET_RV_VPCS offset was mixed up with DL_OFFSET_RG_VPCS, resulting in x2 register value nulling in RG structure. 2. We need to preserve the x8 register before function call, but don't have to save it's new value and restore it before return. Anyway the final restore was using OFFSET_RV instead of OFFSET_RG value which is wrong (althoug doesn't affect anything). Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit eb4181e9f4a512de37dad4ba623c921671584dea)
* Linux: Support __IPC_64 in sysvctl *ctl command arguments (bug 29771)Florian Weimer2022-11-114-26/+63
| | | | | | | | | | | | | | | | | | Old applications pass __IPC_64 as part of the command argument because old glibc did not check for unknown commands, and passed through the arguments directly to the kernel, without adding __IPC_64. Applications need to continue doing that for old glibc compatibility, so this commit enables this approach in current glibc. For msgctl and shmctl, if no translation is required, make direct system calls, as we did before the time64 changes. If translation is required, mask __IPC_64 from the command argument. For semctl, the union-in-vararg argument handling means that translation is needed on all architectures. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit 22a46dee24351fd5f4f188ad80554cad79c82524)
* linux: Fix fstatat on MIPSn64 (BZ #29730)Aurelien Jarno2022-11-021-0/+51
| | | | | | | | | | | | | Commit 6e8a0aac2f883 ("time: Fix overflow itimer tests on 32-bit systems") changed in_time_t_range to assume a 32-bit time_t. This broke fstatat on MIPSn64 that was using it with a 64-bit time_t due to difference between stat and stat64. This commit fix that by adding a MIPSn64 specific version, which bypasses the EOVERFLOW tests. Resolves: BZ #29730 Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit 7457b7eef8dfe8cc48e55b9f9837df6dd397b80d)
* linux: Fix generic struct_stat for 64 bit time (BZ# 29657)Adhemerval Zanella2022-10-256-74/+622
| | | | | | | | | | | | | | | | | | | The generic Linux struct_stat misses the conditionals to use bits/struct_stat_time64_helper.h in the __USE_TIME_BITS64 for architecture that uses __TIMESIZE == 32 (currently csky and nios2). Since newer ports should not support 32 bit time_t, the generic implementation should be used as default. For arm, hppa, and sh a copy of default struct_stat is added, while for csky and nios a new one based on generic is used, along with conditionals to use bits/struct_stat_time64_helper.h. The default struct_stat is also replaced with the generic one. Checked on aarch64-linux-gnu and arm-linux-gnueabihf. (cherry picked from commit 7a6ca82f8007ddbd43e2b8fce806ba7101ee47f5)
* Avoid undefined behaviour in ibm128 implementation of llroundl (BZ #29488)Aurelien Jarno2022-10-241-12/+9
| | | | | | | | | Detecting an overflow edge case depended on signed overflow of a long long. Replace the additions and the overflow checks by __builtin_add_overflow(). Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com> (cherry picked from commit 2b5478569e72ee4820a6e163d306690c9c0eaf5e)
* Fix BZ #29463 in the ibm128 implementation of y1l tooMichael Hudson-Doyle2022-10-241-0/+3
| | | | | | | | | | Avoid moving code across SET_RESTORE_ROUNDL in order to fix [BZ #29463]. Tested-by: Aurelien Jarno <aurelien@aurel32.net> Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com> (cherry picked from commit b6e37b7805b0182c3e25cdab39ebf5f001c04d05)
* Ensure calculations happen with desired rounding mode in y1lf128Michael Hudson-Doyle2022-10-091-0/+3
| | | | | | | | | | | | | math/test-float128-y1 fails on x86_64 and ppc64el with gcc 12 and -O3, because code inside a block guarded by SET_RESTORE_ROUNDL is being moved after the rounding mode has been restored. Use math_force_eval to prevent this (and insert some math_opt_barrier calls to prevent code from being moved before the rounding mode is set). Fixes #29463 Reviewed-By: Wilco Dijkstra <Wilco.Dijkstra@arm.com> (cherry picked from commit 2b274fd8c9c776cf70fcdb8356e678ada522a7b0)
* x86-64: Require BMI1/BMI2 for AVX2 strrchr and wcsrchr implementationsAurelien Jarno2022-10-033-3/+16
| | | | | | | | | | | | The AVX2 strrchr and wcsrchr implementation uses the 'blsmsk' instruction which belongs to the BMI1 CPU feature and the 'shrx' instruction, which belongs to the BMI2 CPU feature. Fixes: df7e295d18ff ("x86: Optimize {str|wcs}rchr-avx2") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> (cherry picked from commit 7e8283170c5d6805b609a040801d819e362a6292)
* x86-64: Require BMI2 and LZCNT for AVX2 memrchr implementationAurelien Jarno2022-10-033-2/+10
| | | | | | | | | | | | The AVX2 memrchr implementation uses the 'shlxl' instruction, which belongs to the BMI2 CPU feature and uses the 'lzcnt' instruction, which belongs to the LZCNT CPU feature. Fixes: af5306a735eb ("x86: Optimize memrchr-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> (cherry picked from commit 3c0c78afabfed4b6fc161c159e628fbf14ff370b)
* x86-64: Require BMI2 for AVX2 (raw|w)memchr implementationsAurelien Jarno2022-10-031-3/+9
| | | | | | | | | | | The AVX2 memchr, rawmemchr and wmemchr implementations use the 'bzhi' and 'sarx' instructions, which belongs to the BMI2 CPU feature. Fixes: acfd088a1963 ("x86: Optimize memchr-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> (cherry picked from commit e3e7fab7fe5186d18ca2046d99ba321c27db30ad)
* x86-64: Require BMI2 for AVX2 wcs(n)cmp implementationsAurelien Jarno2022-10-031-2/+6
| | | | | | | | | | | | | | | The AVX2 wcs(n)cmp implementations use the 'bzhi' instruction, which belongs to the BMI2 CPU feature. NB: It also uses the 'tzcnt' BMI1 instruction, but it is executed as BSF as BSF if the CPU doesn't support TZCNT, and produces the same result for non-zero input. Partially fixes: b77b06e0e296 ("x86: Optimize strcmp-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> (cherry picked from commit f31a5a884ed84bd37032729d4d1eb9d06c9f3c29)
* x86-64: Require BMI2 for AVX2 strncmp implementationAurelien Jarno2022-10-032-4/+7
| | | | | | | | | | | | | | | The AVX2 strncmp implementations uses the 'bzhi' instruction, which belongs to the BMI2 CPU feature. NB: It also uses the 'tzcnt' BMI1 instruction, but it is executed as BSF as BSF if the CPU doesn't support TZCNT, and produces the same result for non-zero input. Partially fixes: b77b06e0e296 ("x86: Optimize strcmp-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> (cherry picked from commit fc7de1d9b99ae1676bc626ddca422d7abee0eb48)
* x86-64: Require BMI2 for AVX2 strcmp implementationAurelien Jarno2022-10-032-3/+5
| | | | | | | | | | | | | | | The AVX2 strcmp implementation uses the 'bzhi' instruction, which belongs to the BMI2 CPU feature. NB: It also uses the 'tzcnt' BMI1 instruction, but it is executed as BSF as BSF if the CPU doesn't support TZCNT, and produces the same result for non-zero input. Partially fixes: b77b06e0e296 ("x86: Optimize strcmp-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> (cherry picked from commit 4d64c6445735e9b34e2ac8e369312cbfc2f88e17)
* x86-64: Require BMI2 for AVX2 str(n)casecmp implementationsAurelien Jarno2022-10-032-8/+21
| | | | | | | | | | | | | | | The AVX2 str(n)casecmp implementations use the 'bzhi' instruction, which belongs to the BMI2 CPU feature. NB: It also uses the 'tzcnt' BMI1 instruction, but it is executed as BSF as BSF if the CPU doesn't support TZCNT, and produces the same result for non-zero input. Partially fixes: b77b06e0e296 ("x86: Optimize strcmp-avx2.S") Partially resolves: BZ #29611 Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> (cherry picked from commit 10f79d3670b036925da63dc532b122d27ce65ff8)
* x86: include BMI1 and BMI2 in x86-64-v3 levelAurelien Jarno2022-10-031-0/+2
| | | | | | | | | The "System V Application Binary Interface AMD64 Architecture Processor Supplement" mandates the BMI1 and BMI2 CPU features for the x86-64-v3 level. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com> (cherry picked from commit b80f16adbd979831bf25ea491e1261e81885c2b6)
* hppa: undef __ASSUME_SET_ROBUST_LISTJohn David Anglin2022-10-011-0/+3
| | | | | | | QEMU does not support support set_robust_list. Thus, we need to enable detection of set_robust_list system call. Signed-off-by: John David Anglin <dave.anglin@bell.net>
* hppa: Fix initialization of dp register [BZ 29635]John David Anglin2022-10-011-5/+19
| | | | | | | | | | | | | After upgrading glibc to Debian 2.35-1, gdb faulted on startup and dropped core in a function call in the main application. This was caused by not initializing the global dp register for the main application early enough. Restore the code to initialize dp in _dl_start_user. It was removed when code was added to initialize dp in elf_machine_runtime_setup. Signed-off-by: John David Anglin <dave.anglin@bell.net>
* stdlib: Fix __getrandom_nocancel type and arc4random usage (BZ #29638)Adhemerval Zanella2022-09-301-1/+1
| | | | | | | | | | Using an unsigned type prevents the fallback to be used if kernel does not support getrandom syscall. Checked on x86_64-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com> (cherry picked from commit 13db9ee2cb3b77e25f852be7d6952882e1be6f00)
* get_nscd_addresses: Fix subscript typos [BZ #29605]Jörg Sonnenberger2022-09-281-3/+3
| | | | | | | | | | Fix the subscript on air->family, which was accidentally set to COUNT when it should have remained as I. Resolves: BZ #29605 Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit c9226c03da0276593a0918eaa9a14835183343e8)
* m68k: Enforce 4-byte alignment on internal locks (BZ #29537)Adhemerval Zanella2022-09-214-2/+59
| | | | | | | | | | A new internal definition, __LIBC_LOCK_ALIGNMENT, is used to force the 4-byte alignment only for m68k, other architecture keep the natural alignment of the type used internally (and hppa does not require 16-byte alignment for kernel-assisted CAS). Reviewed-by: Florian Weimer <fweimer@redhat.com> (cherry picked from commit aeb4d2e9815d459e2640a31f5abb8ef803830107)
* elf: Rename _dl_sort_maps parameter from skip to force_firstFlorian Weimer2022-09-201-2/+4
| | | | | | | | The new implementation will not be able to skip an arbitrary number of objects. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit dbb75513f5cf9285c77c9e55777c5c35b653f890)
* Linux: Fix enum fsconfig_command detection in <sys/mount.h>Florian Weimer2022-08-241-3/+3
| | | | | | | | | | | The #ifdef FSOPEN_CLOEXEC check did not work because the macro was always defined in this header prior to the check, so that the <linux/mount.h> contents did not matter. Fixes commit 774058d72942249f71d74e7f2b639f77184160a6 ("linux: Fix sys/mount.h usage with kernel headers"). (cherry picked from commit 2955ef4b7c9b56fcd7abfeddef7ee83c60abff98)
* linux: Fix sys/mount.h usage with kernel headersAdhemerval Zanella2022-08-243-8/+137
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that kernel exports linux/mount.h and includes it on linux/fs.h, its definitions might clash with glibc exports sys/mount.h. To avoid the need to rearrange the Linux header to be always after glibc one, the glibc sys/mount.h is changed to: 1. Undefine the macros also used as enum constants. This covers prior inclusion of <linux/mount.h> (for instance MS_RDONLY). 2. Include <linux/mount.h> based on the usual __has_include check (needs to use __has_include ("linux/mount.h") to paper over GCC bugs. 3. Define enum fsconfig_command only if FSOPEN_CLOEXEC is not defined. (FSOPEN_CLOEXEC should be a very close proxy.) 4. Define struct mount_attr if MOUNT_ATTR_SIZE_VER0 is not defined. (Added in the same commit on the Linux side.) This patch also adds some tests to check if including linux/fs.h and linux/mount.h after and before sys/mount.h does work. Checked on x86_64-linux-gnu. Reviewed-by: Florian Weimer <fweimer@redhat.com> (cherry picked from commit 774058d72942249f71d74e7f2b639f77184160a6)
* linux: Use compile_c_snippet to check linux/mount.h availabilityAdhemerval Zanella2022-08-241-0/+5
| | | | | | | Checked on x86_64-linux-gnu. Reviewed-by: Florian Weimer <fweimer@redhat.com> (cherry picked from commit e1226cdc6b209539a92d32d5b620ba53fd35abf3)
* linux: Mimic kernel defition for BLOCK_SIZEAdhemerval Zanella2022-08-241-1/+1
| | | | | | | | To avoid possible warnings if the kernel header is included before sys/mount.h. Reviewed-by: Florian Weimer <fweimer@redhat.com> (cherry picked from commit c68b6044bc7945716431f1adc091b17c39b80a06)
* linux: Use compile_c_snippet to check linux/pidfd.h availabilityAdhemerval Zanella2022-08-241-4/+6
| | | | | | | | | Instead of tying to a specific kernel version. Checked on x86_64-linux-gnu. Reviewed-by: Florian Weimer <fweimer@redhat.com> (cherry picked from commit 1542019b69b7ec7b2cd34357af035e406d153631)
* socket: Check lengths before advancing pointer in CMSG_NXTHDRArjun Shankar2022-08-223-22/+94
| | | | | | | | | | | | | | | | | | The inline and library functions that the CMSG_NXTHDR macro may expand to increment the pointer to the header before checking the stride of the increment against available space. Since C only allows incrementing pointers to one past the end of an array, the increment must be done after a length check. This commit fixes that and includes a regression test for CMSG_FIRSTHDR and CMSG_NXTHDR. The Linux, Hurd, and generic headers are all changed. Tested on Linux on armv7hl, i686, x86_64, aarch64, ppc64le, and s390x. [BZ #28846] Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit 9c443ac4559a47ed99859bd80d14dc4b6dd220a1)
* alpha: Fix generic brk system call emulation in __brk_call (bug 29490)Florian Weimer2022-08-221-4/+3
| | | | | | | | | | The kernel special-cases the zero argument for alpha brk, and we can use that to restore the generic Linux error handling behavior. Fixes commit b57ab258c1140bc45464b4b9908713e3e0ee35aa ("Linux: Introduce __brk_call for invoking the brk system call"). (cherry picked from commit e7ad26ee3cb74e61d0637c888f24dd478d77af58)
* Linux: Terminate subprocess on late failure in tst-pidfd (bug 29485)Florian Weimer2022-08-161-2/+5
| | | | | Reviewed-by: Carlos O'Donell <carlos@redhat.com> (cherry picked from commit f82e05ebb295cadd35f7372f652c72264da810ad)
* Update syscall lists for Linux 5.19Joseph Myers2022-08-053-2/+4
| | | | | | | | | | | Linux 5.19 has no new syscalls, but enables memfd_secret in the uapi headers for RISC-V. Update the version number in syscall-names.list to reflect that it is still current for 5.19 and regenerate the arch-syscall.h headers with build-many-glibcs.py update-syscalls. Tested with build-many-glibcs.py. (cherry picked from commit fccadcdf5bed7ee67a6cef4714e0b477d6c8472c)
* tst-pidfd.c: UNSUPPORTED if we get EPERM on valid pidfd_getfd callMark Wielaard2022-07-291-0/+7
| | | | | | | | pidfd_getfd can fail for a valid pidfd with errno EPERM for various reasons in a restricted environment. Use FAIL_UNSUPPORTED in that case. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* LoongArch: Add greg_t and gregset_t.caiyinyu2022-07-291-0/+3
|
* LoongArch: Fix VDSO_HASH and VDSO_NAME.caiyinyu2022-07-291-2/+2
|
* riscv: Update rv64 libm test ulpsDarius Rad2022-07-271-1/+1
| | | | | | Generated on a Microsemi Polarfire Icicle Kit running Linux version 5.15.32. Same ULPs were also produced on QEMU 5.2.0 running Linux 5.18.0.
* riscv: Update nofpu libm test ulpsDarius Rad2022-07-271-31/+39
|
* arc4random: simplify design for better safetyJason A. Donenfeld2022-07-2726-2079/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than buffering 16 MiB of entropy in userspace (by way of chacha20), simply call getrandom() every time. This approach is doubtlessly slower, for now, but trying to prematurely optimize arc4random appears to be leading toward all sorts of nasty properties and gotchas. Instead, this patch takes a much more conservative approach. The interface is added as a basic loop wrapper around getrandom(), and then later, the kernel and libc together can work together on optimizing that. This prevents numerous issues in which userspace is unaware of when it really must throw away its buffer, since we avoid buffering all together. Future improvements may include userspace learning more from the kernel about when to do that, which might make these sorts of chacha20-based optimizations more possible. The current heuristic of 16 MiB is meaningless garbage that doesn't correspond to anything the kernel might know about. So for now, let's just do something conservative that we know is correct and won't lead to cryptographic issues for users of this function. This patch might be considered along the lines of, "optimization is the root of all evil," in that the much more complex implementation it replaces moves too fast without considering security implications, whereas the incremental approach done here is a much safer way of going about things. Once this lands, we can take our time in optimizing this properly using new interplay between the kernel and userspace. getrandom(0) is used, since that's the one that ensures the bytes returned are cryptographically secure. But on systems without it, we fallback to using /dev/urandom. This is unfortunate because it means opening a file descriptor, but there's not much of a choice. Secondly, as part of the fallback, in order to get more or less the same properties of getrandom(0), we poll on /dev/random, and if the poll succeeds at least once, then we assume the RNG is initialized. This is a rough approximation, as the ancient "non-blocking pool" initialized after the "blocking pool", not before, and it may not port back to all ancient kernels, though it does to all kernels supported by glibc (≥3.2), so generally it's the best approximation we can do. The motivation for including arc4random, in the first place, is to have source-level compatibility with existing code. That means this patch doesn't attempt to litigate the interface itself. It does, however, choose a conservative approach for implementing it. Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Florian Weimer <fweimer@redhat.com> Cc: Cristian Rodríguez <crrodriguez@opensuse.org> Cc: Paul Eggert <eggert@cs.ucla.edu> Cc: Mark Harris <mark.hsj@gmail.com> Cc: Eric Biggers <ebiggers@kernel.org> Cc: linux-crypto@vger.kernel.org Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-08-15 23:03:57 +0000