about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
...
* rt: fix shm_open not set ENAMETOOLONG when name exceeds {_POSIX_PATH_MAX}abushwang2023-03-083-7/+15
| | | | | | | | according to man-pages-posix-2017, shm_open() function may fail if the length of the name argument exceeds {_POSIX_PATH_MAX} and set ENAMETOOLONG Signed-off-by: abushwang <abushwangs@gmail.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* posix: Ensure the initial signal disposition for tst-spawn7Adhemerval Zanella Netto2023-03-081-0/+6
| | | | | | | | | | To avoid possible failure if any parent set any initial signal disposition as SIG_IGN (for instance if the testcase is issued with nohup). Checked on x86_64-linux-gnu. Tested-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Florian Weimer <fweimer@redhat.com>
* hurd: fix build of tst-system.cAdam Yi2023-03-081-0/+1
| | | | | | | | | | | | We made tst-system.c depend on pthread, but that requires linking with $(shared-thread-library). It does not fail under Linux because the variable expands to nothing under Linux, but it fails for Hurd. I tested verified via cross-compiling that "make check" now works for Hurd. Signed-off-by: Adam Yi <ayi@janestreet.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* x86: Fix bug about glibc.cpu.hwcaps.caiyinyu2023-03-071-3/+3
| | | | | | | | | | | | | | | | | | | Recorded in [BZ #30183]: 1. export GLIBC_TUNABLES=glibc.cpu.hwcaps=-AVX512 2. Add _dl_printf("p -- %s\n", p); just before switch(nl) in sysdeps/x86/cpu-tunables.c 3. compiled and run ./testrun.sh /usr/bin/ls you will get: p -- -AVX512 p -- LC_ADDRESS=en_US.UTF-8 p -- LC_NUMERIC=C ... The function, TUNABLE_CALLBACK (set_hwcaps) (tunable_val_t *valp), checks far more than it should and it should stop at end of "-AVX512".
* posix: Fix system blocks SIGCHLD erroneously [BZ #30163]Adam Yi2023-03-077-3/+140
| | | | | | | | | | | | | | | | | | | | | 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>
* gshadow: Matching sgetsgent, sgetsgent_r ERANGE handling (bug 30151)Florian Weimer2023-03-073-2/+74
| | | | | | | | | | | | | 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>
* Update kernel version to 6.2 in header constant testsJoseph Myers2023-03-063-4/+4
| | | | | | | | | | This patch updates the kernel version in the tests tst-mman-consts.py, tst-mount-consts.py and tst-pidfd-consts.py to 6.2. (There are no new constants covered by these tests in 6.2 that need any other header changes, and the removed MAP_VARIABLE for hppa was addressed separately.) Tested with build-many-glibcs.py.
* arm: Remove __builtin_arm_uqsub8 usage on string-fza.hAdhemerval Zanella Netto2023-03-021-4/+0
| | | | | | | | | | The __builtin_arm_uqsub8 is an internal GCC builtin which might change in future release (the correct way is to include "arm_acle.h" and use __uqsub8 ()). Since not all compilers support it, just use the inline assembler instead. Checked on armv7a-linux-gnueabihf. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* alpha: Remove strncmp optimizationAdhemerval Zanella Netto2023-03-021-276/+0
| | | | | | | The generic implementation already cover word access along with cmpbge for both aligned and unaligned, so use it instead. Checked qemu static for alpha-linux-gnu.
* powerpc: Remove powerpc64 strncmp variantsAdhemerval Zanella Netto2023-03-028-494/+9
| | | | | | | | | | | | | The default, and power7 implementation just adds word aligned access when inputs have the same aligment. The unaligned case is still done by byte operations. This is already covered by the generic implementation, which also add the unaligned input optimization. Checked on powerpc64-linux-gnu built without multi-arch for powerpc64, power7, power8, and power9 (build for le). Reviewed-by: Rajalakshmi Srinivasaraghavan <rajis@linux.ibm.com>
* powerpc: Remove strncmp variantsAdhemerval Zanella Netto2023-03-028-701/+1
| | | | | | | | | | | | | The default, power4, and power7 implementation just adds word aligned access when inputs have the same aligment. The unaligned case is still done by byte operations. This is already covered by the generic implementation, which also add the unaligned input optimization. Checked on powerpc-linux-gnu built without multi-arch for powerpc, power4, and power7. Reviewed-by: Rajalakshmi Srinivasaraghavan <rajis@linux.ibm.com>
* C2x scanf binary constant handlingJoseph Myers2023-03-02127-29/+2582
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | C2x adds binary integer constants starting with 0b or 0B, and supports those constants for the %i scanf format (in addition to the %b format, which isn't yet implemented for scanf in glibc). Implement that scanf support for glibc. As with the strtol support, this is incompatible with previous C standard versions, in that such an input string starting with 0b or 0B was previously required to be parsed as 0 (with the rest of the input potentially matching subsequent parts of the scanf format string). Thus this patch adds 12 new __isoc23_* functions per long double format (12, 24 or 36 depending on how many long double formats the glibc configuration supports), with appropriate header redirection support (generally very closely following that for the __isoc99_* scanf functions - note that __GLIBC_USE (DEPRECATED_SCANF) takes precedence over __GLIBC_USE (C2X_STRTOL), so the case of GNU extensions to C89 continues to get old-style GNU %a and does not get this new feature). The function names would remain as __isoc23_* even if C2x ends up published in 2024 rather than 2023. When scanf %b support is added, I think it will be appropriate for all versions of scanf to follow C2x rules for inputs to the %b format (given that there are no compatibility concerns for a new format). Tested for x86_64 (full glibc testsuite). The first version was also tested for powerpc (32-bit) and powerpc64le (stdio-common/ and wcsmbs/ tests), and with build-many-glibcs.py.
* Fix stringop-overflow warning in test-strncat.Stefan Liebler2023-03-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | Starting with commit b2c474f8de4c92bfe7435853a96805ec32d68dfa "x86: Fix strncat-avx2.S reading past length [BZ #30065]" Building on s390 the test fails due warnings like: In function ‘do_one_test’, inlined from ‘do_overflow_tests’ at test-strncat.c:175:7: test-strncat.c:31:18: error: ‘strnlen’ specified bound [4294966546, 4294967295] exceeds maximum object size 2147483647 [-Werror=stringop-overflow=] 31 | # define STRNLEN strnlen | ^ test-strncat.c:83:16: note: in expansion of macro ‘STRNLEN’ 83 | size_t len = STRNLEN (src, n); | ^~~~~~~ In all werror cases, the call to strnlen (.., SIZE_MAX) is inlined. Therefore this patch just marks the do_one_test function as noinline. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* nis: Fix stringop-truncation warning with -O3 in nis_local_host.Stefan Liebler2023-03-021-3/+7
| | | | | | | | | | | | | | | | | | | | | | When building with -O3 on s390x/x86_64, I get this stringop-truncation warning which leads to a build fail: In function ‘nis_local_host’, inlined from ‘nis_local_host’ at nis_local_names.c:147:1: nis_local_names.c:171:11: error: ‘strncpy’ output may be truncated copying between 0 and 1023 bytes from a string of length 1024 [-Werror=stringop-truncation] 171 | strncpy (cp, nis_local_directory (), NIS_MAXNAMELEN - len -1); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We can just ignore this warning as the hostname + '.' + directory-name + '\0' always fits in __nishostname with length of (NIS_MAXNAMELEN + 1) as there is the runtime check above. Furthermore as we already know the length of the directory-name, we can also just use memcpy to copy the directory-name inclusive the NUL-termination. Note: This werror was introduced with commit 32c7acd46401530fdbd4e98508c9baaa705f8b53 "Replace rawmemchr (s, '\0') with strchr" Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* support: use 64-bit time_t (bug 30111)Andreas Schwab2023-03-026-8/+22
| | | | Ensure to use 64-bit time_t in the test infrastructure.
* LoongArch: Update libm-test-ulps.caiyinyu2023-03-021-0/+1
|
* LoongArch: Further refine the condition to enable static PIEXi Ruoyao2023-03-022-0/+7
| | | | | | | | | | | | Before GCC r13-2728, it would produce a normal dynamic-linked executable with -static-pie. I mistakely believed it would produce a static-linked executable, so failed to detect the breakage. Then with Binutils 2.40 and (vanilla) GCC 12, libc_cv_static_pie_on_loongarch is mistakenly enabled and cause a building failure with "undefined reference to _DYNAMIC". Fix the issue by disabling static PIE if -static-pie creates something with a INTERP header.
* hurd: Fix some broken indentationSergey Bugaev2023-03-021-50/+51
| | | | | | | Also, fix a couple of typos. No functional change. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230301162355.426887-2-bugaevc@gmail.com>
* hurd: Remove the ecx kludgeSergey Bugaev2023-03-023-48/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "We don't need it any more" The INTR_MSG_TRAP macro in intr-msg.h used to play little trick with the stack pointer: it would temporarily save the "real" stack pointer into ecx, while setting esp to point to just before the message buffer, and then invoke the mach_msg trap. This way, INTR_MSG_TRAP reused the on-stack arguments laid out for the containing call of _hurd_intr_rpc_mach_msg (), passing them to the mach_msg trap directly. This, however, required special support in hurdsig.c and trampoline.c, since they now had to recognize when a thread is inside the piece of code where esp doesn't point to the real tip of the stack, and handle this situation specially. Commit 1d20f33ff4fb634310f27493b7b87d0b20f4a0b0 has removed the actual temporary change of esp by actually re-pushing mach_msg arguments onto the stack, and popping them back at end. It did not, however, deal with the rest of "the ecx kludge" code in other files, resulting in potential crashes if a signal arrives in the middle of pushing arguments onto the stack. Fix that by removing "the ecx kludge". Instead, when we want a thread to skip the RPC, but cannot make just make it jump to after the trap since it's not done adjusting the stack yet, set the SYSRETURN register to MACH_SEND_INTERRUPTED (as we do anyway), and rely on the thread itself for detecting this case and skipping the RPC. This simplifies things somewhat and paves the way for a future x86_64 port of this code. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230301162355.426887-1-bugaevc@gmail.com>
* Add AArch64 HWCAP2 values from Linux 6.2 to bits/hwcap.hJoseph Myers2023-02-281-0/+3
| | | | | | | Linux 6.2 adds three new AArch64 HWCAP2 values; add them to glibc's AArch64 bits/hwcap.h. Tested with build-many-glibcs.py for aarch64-linux-gnu.
* crypt: Remove invalid end of page test badsalttestAdhemerval Zanella2023-02-281-43/+9
| | | | | | | | | | | | | The input argument passes an invalid string without a NUL terminator on crypt settings inputs, which might lead to invalid OOB on strncmp. Implementations only assume there is a NUL terminator if the string is shorter than the specified size, so strings don't need to always be NUL terminated (stratcliff.c has tests for this). Also adapt the code to use libsupport. Checked on arm-linux-gnuabihf.
* S390: Fix _FPU_SETCW/GETCW when compiling with Clang [BZ #30130]Andreas Arnez2023-02-281-2/+2
| | | | | | | | The _FPU_SETCW and _FPU_GETCW macros are defined with inline assemblies. They use the sfpc and efpc instructions, respectively. But both contain a spurious second operand that leads to a compile error with Clang. Removing this operand works both with gcc/gas (since binutils 2.18) as well as with clang/llvm.
* s390x: Regenerate ULPs.Stefan Liebler2023-02-281-0/+1
| | | | | | | | | Needed due to recent commits: - "added pair of inputs for hypotf in binary32" commit ID cf7ffdd8a5f6da55397e10b3860062944312824c - "update auto-libm-test-out-hypot" commit ID 3efbf11fdf15ed991d2c41743921c524a867e145
* Add Arm HWCAP values from Linux 6.2 to bits/hwcap.hJoseph Myers2023-02-283-6/+13
| | | | | | | | Linux 6.2 adds six new Arm HWCAP values and two new HWCAP2 values; add them to glibc's Arm bits/hwcap.h, with corresponding dl-procinfo.c and dl-procinfo.h updates. Tested with build-many-glibcs.py for arm-linux-gnueabi.
* htl: Add pthreadtypes-arch.h for x86_64Sergey Bugaev2023-02-271-0/+36
| | | | | Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230221211932.296459-5-bugaevc@gmail.com>
* hurd: Implement TLS for x86_64Sergey Bugaev2023-02-272-1/+228
| | | | | Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230221211932.296459-4-bugaevc@gmail.com>
* htl: Make pthread_mutex_t pointer-alignedSergey Bugaev2023-02-271-5/+8
| | | | | | | | This is for future-proofing. On i386, it is 4-byte aligned anyway, but on x86_64, we want it 8-byte aligned, not 4-byte aligned. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230214173722.428140-4-bugaevc@gmail.com>
* x86_64: Update libm test ulpsH.J. Lu2023-02-271-0/+1
| | | | | | | | | | | | Update libm test ulps for commit 3efbf11fdf15ed991d2c41743921c524a867e145 Author: Paul Zimmermann <Paul.Zimmermann@inria.fr> Date: Tue Feb 14 11:24:59 2023 +0100 update auto-libm-test-out-hypot Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* localedata: de_DE should not use FräuleinFlorian Weimer2023-02-271-1/+1
| | | | This honorific has fallen out of use quite some time ago.
* LoongArch: Add math-barriers.hXi Ruoyao2023-02-271-0/+28
| | | | | | | | This patch implements the LoongArch specific math barriers in order to omit the store and load from stack if possible. Signed-off-by: Xi Ruoyao <xry111@xry111.site> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* cdefs.h: fix "__clang_major" typoPaul Eggert2023-02-271-1/+1
| | | | | * misc/sys/cdefs.h: Fix misspelling of "__clang_major__". Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* hppa: Drop old parisc-specific MADV_* constantsJohn David Anglin2023-02-252-29/+6
| | | | | | | | | | | | | | | | | | | The Linux kernel upstream commit 71bdea6f798b ("parisc: Align parisc MADV_XXX constants with all other architectures") dropped the parisc-specific MADV_* values in favour of the same constants as other architectures. In the same commit a wrapper was added which translates the old values to the standard MADV_* values to avoid breakage of existing programs. This upstream patch has been downported to all stable kernel trees as well. This patch now drops the parisc specific constants from glibc to allow newly compliled programs to use the standard MADV_* constants. v2: Added NEWS section, based on feedback from Florian Weimer Signed-off-by: Helge Deller <deller@gmx.de>
* hurd: Generalize init-first.c to support x86_64Sergey Bugaev2023-02-241-0/+6
| | | | | Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230223151436.49180-2-bugaevc@gmail.com>
* hurd: Simplify init-first.c furtherSergey Bugaev2023-02-244-140/+68
| | | | | | | | This drops all of the return address rewriting kludges. The only remaining hack is the jump out of a call stack while adjusting the stack pointer. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
* hurd: Mark some audit tests as unsupportedSamuel Thibault2023-02-241-0/+10
| | | | They hang the testsuite.
* htl: Mark select loop test as unsupportedSamuel Thibault2023-02-241-0/+6
| | | | It overflows pflocal and doesn't manage to terminate.
* hurd: Mark RLIMIT_AS tests as unsupportedSamuel Thibault2023-02-241-0/+11
| | | | Otherwise they put the system on its knees.
* aarch64: update libm test ulpsSzabolcs Nagy2023-02-241-0/+1
|
* powerpc:Regenerate ulps for hypotMahesh Bodapati2023-02-231-0/+4
| | | | | For new inputs added in commit 3efbf11fdf15ed991d2c41743921c524a867e145, regenerate the ulps of hypot from 0(default) to 1
* Update syscall lists for Linux 6.2Joseph Myers2023-02-231-2/+2
| | | | | | | Linux 6.2 has no new syscalls. Update the version number in syscall-names.list to reflect that it is still current for 6.2. Tested with build-many-glibcs.py.
* tunables.texi: Change \code{1} to @code{1}H.J. Lu2023-02-231-1/+1
| | | | | | Update 317f1c0a8a x86-64: Add glibc.cpu.prefer_map_32bit_exec [BZ #28656]
* x86-64: Add glibc.cpu.prefer_map_32bit_exec [BZ #28656]H.J. Lu2023-02-229-9/+205
| | | | | | | | | | | | | | | | | | | Crossing 2GB boundaries with indirect calls and jumps can use more branch prediction resources on Intel Golden Cove CPU (see the "Misprediction for Branches >2GB" section in Intel 64 and IA-32 Architectures Optimization Reference Manual.) There is visible performance improvement on workloads with many PLT calls when executable and shared libraries are mmapped below 2GB. Add the Prefer_MAP_32BIT_EXEC bit so that mmap will try to map executable or denywrite pages in shared libraries with MAP_32BIT first. NB: Prefer_MAP_32BIT_EXEC reduces bits available for address space layout randomization (ASLR), which is always disabled for SUID programs and can only be enabled by the tunable, glibc.cpu.prefer_map_32bit_exec, or the environment variable, LD_PREFER_MAP_32BIT_EXEC. This works only between shared libraries or between shared libraries and executables with addresses below 2GB. PIEs are usually loaded at a random address above 4GB by the kernel.
* gmon: fix memory corruption issues [BZ# 30101]Simon Kissane2023-02-223-8/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* gmon: improve mcount overflow handling [BZ# 27576]Simon Kissane2023-02-228-7/+244
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* gmon: Fix allocated buffer overflow (bug 29444)Леонид Юрьев (Leonid Yuriev)2023-02-221-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* malloc: remove redundant check of unsorted bin corruptionAyush Mittal2023-02-221-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | * malloc/malloc.c (_int_malloc): remove redundant check of unsorted bin corruption With commit "b90ddd08f6dd688e651df9ee89ca3a69ff88cd0c" (malloc: Additional checks for unsorted bin integrity), same check of (bck->fd != victim) is added before checking of unsorted chunk corruption, which was added in "bdc3009b8ff0effdbbfb05eb6b10966753cbf9b8" (Added check before removing from unsorted list). .. 3773 if (__glibc_unlikely (bck->fd != victim) 3774 || __glibc_unlikely (victim->fd != unsorted_chunks (av))) 3775 malloc_printerr ("malloc(): unsorted double linked list corrupted"); .. .. 3815 /* remove from unsorted list */ 3816 if (__glibc_unlikely (bck->fd != victim)) 3817 malloc_printerr ("malloc(): corrupted unsorted chunks 3"); 3818 unsorted_chunks (av)->bk = bck; .. So this extra check can be removed. Signed-off-by: Maninder Singh <maninder1.s@samsung.com> Signed-off-by: Ayush Mittal <ayush.m@samsung.com> Reviewed-by: DJ Delorie <dj@redhat.com>
* Use Linux 6.2 in build-many-glibcs.pyJoseph Myers2023-02-221-1/+1
| | | | | | | This patch makes build-many-glibcs.py use Linux 6.2. Tested with build-many-glibcs.py (host-libraries, compilers and glibcs builds).
* Ignore MAP_VARIABLE in tst-mman-consts.pyJoseph Myers2023-02-221-2/+5
| | | | | | | | | | | Linux 6.2 removed the hppa compatibility MAP_VARIABLE define. That means that, whether or not we remove it in glibc, it needs to be ignored in tst-mman-consts.py (since this macro comparison infrastructure expects that new kernel header versions only add new macros, not remove old ones). Tested with build-many-glibcs.py for hppa-linux-gnu (Linux 6.2 headers).
* AArch64: Fix HP_TIMING_DIFF computation [BZ# 29329]Jun Tang2023-02-221-1/+1
| | | | | | | | Fix the computation to allow for cntfrq_el0 being larger than 1GHz. Assume cntfrq_el0 is a multiple of 1MHz to increase the maximum interval (1024 seconds at 1GHz). Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* s390: Fix build for -march=z13Adhemerval Zanella2023-02-202-0/+2
| | | | | | | | It fixes the build after 7ea510127e2067e and 22999b2f0fb62. Checked with build for s390x-linux-gnu with -march=z13. Reviewed-by: Arjun Shankar <arjun@redhat.com>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-28 14:08:04 +0000