about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* libsupport: Add support_select_modifies_timeoutAdhemerval Zanella2021-04-123-0/+34
| | | | It will be used on a select() test.
* Fix SXID_ERASE behavior in setuid programs (BZ #27471)Siddhesh Poyarekar2021-04-122-30/+52
| | | | | | | | | | | | | | | | | | | | | | | | | When parse_tunables tries to erase a tunable marked as SXID_ERASE for setuid programs, it ends up setting the envvar string iterator incorrectly, because of which it may parse the next tunable incorrectly. Given that currently the implementation allows malformed and unrecognized tunables pass through, it may even allow SXID_ERASE tunables to go through. This change revamps the SXID_ERASE implementation so that: - Only valid tunables are written back to the tunestr string, because of which children of SXID programs will only inherit a clean list of identified tunables that are not SXID_ERASE. - Unrecognized tunables get scrubbed off from the environment and subsequently from the child environment. - This has the side-effect that a tunable that is not identified by the setxid binary, will not be passed on to a non-setxid child even if the child could have identified that tunable. This may break applications that expect this behaviour but expecting such tunables to cross the SXID boundary is wrong. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Enhance setuid-tunables testSiddhesh Poyarekar2021-04-122-23/+69
| | | | | | | | | | Instead of passing GLIBC_TUNABLES via the environment, pass the environment variable from parent to child. This allows us to test multiple variables to ensure better coverage. The test list currently only includes the case that's already being tested. More tests will be added later. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* tst-env-setuid: Use support_capture_subprogram_self_sgidSiddhesh Poyarekar2021-04-121-183/+14
| | | | | Use the support_capture_subprogram_self_sgid to spawn an sgid child. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* support: Add capability to fork an sgid childSiddhesh Poyarekar2021-04-125-181/+168
| | | | | | | | | | | | | | | | | | | | Add a new function support_capture_subprogram_self_sgid that spawns an sgid child of the running program with its own image and returns the exit code of the child process. This functionality is used by at least three tests in the testsuite at the moment, so it makes sense to consolidate. There is also a new function support_subprogram_wait which should provide simple system() like functionality that does not set up file actions. This is useful in cases where only the return code of the spawned subprocess is interesting. This patch also ports tst-secure-getenv to this new function. A subsequent patch will port other tests. This also brings an important change to tst-secure-getenv behaviour. Now instead of succeeding, the test fails as UNSUPPORTED if it is unable to spawn a setgid child, which is how it should have been in the first place. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* arm: Fix an incorrect check in ____longjmp_chk [BZ #27709]Szabolcs Nagy2021-04-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | An incorrect check in __longjmp_chk could fail on valid code causing FAIL: debug/tst-longjmp_chk2 The original check was altstack_sp + altstack_size - setjmp_sp > altstack_size i.e. sp at setjmp was outside of the altstack range. Here we know that longjmp is called from a signal handler on the altstack (SS_ONSTACK), and that it jumps in the wrong direction (sp decreases), so the check wants to ensure the jump goes to another stack. The check is wrong when altstack_sp == setjmp_sp which can happen when the altstack is a local buffer in the function that calls setjmp, so the patch allows == too. This fixes bug 27709. Note that the generic __longjmp_chk check seems to be different. (it checks if longjmp was on the altstack but does not check setjmp, so it would not catch incorrect longjmp use within the signal handler).
* Further fixes for REALLOC_ZERO_BYTES_FREES commentPaul Eggert2021-04-121-7/+8
| | | | * malloc/malloc.c (REALLOC_ZERO_BYTES_FREES): Improve comment further.
* hurd: Export _hurd_libc_proc_initSamuel Thibault2021-04-123-0/+9
| | | | | hurd's libdiskfs needs to be able to call _hurd_init + _hurd_libc_proc_init for bootstrap initialization.
* Fix REALLOC_ZERO_BYTES_FREES comment to match C17Paul Eggert2021-04-111-4/+7
| | | | | * malloc/malloc.c (REALLOC_ZERO_BYTES_FREES): Update comment to match current C standard.
* powerpc: Update libm test ulpsTulio Magno Quites Machado Filho2021-04-091-10/+10
| | | | Update after commit 43576de04afc6a0896a3ecc094e1581069a0652a.
* arm: update libm test ulpsSzabolcs Nagy2021-04-081-25/+25
| | | | | Updated after commits 9acda61d94acc5348c2330f2519a14d1a4a37e73 and 43576de04afc6a0896a3ecc094e1581069a0652a.
* aarch64: update libm test ulpsSzabolcs Nagy2021-04-081-1/+1
| | | | Update after commit 43576de04afc6a0896a3ecc094e1581069a0652a.
* Improve the accuracy of tgamma (BZ #26983)Paul Zimmermann2021-04-075-15/+375
| | | | | | | | | | | | With this patch, the maximal known error for tgamma is now reduced to 9 ulps for dbl-64, for all rounding modes. Since exhaustive testing is not possible for dbl-64, it might be that there are still cases with an error larger than 9 ulps, but all known cases are fixed (intensive tests were done to find cases with large errors). Tested on x86_64 and powerpc (and by Adhemerval Zanella on aarch64, arm, s390x, sparc, and i686). Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* tunables: Fix comparison of tunable valuesSiddhesh Poyarekar2021-04-073-11/+49
| | | | | | | | | | The simplification of tunable_set interfaces took care of signed/unsigned conversions while setting values, but comparison with bounds ended up being incorrect; comparing TUNABLE_SIZE_T values for example will fail because SIZE_MAX is seen as -1. Add comparison helpers that take tunable types into account and use them to do comparison instead.
* sys: Fixes possible typo in comment: statfs -> statvfsHugo Gabriel Eyherabide2021-04-071-1/+1
|
* malloc: Run tst-malloc-stats-cancellation via test-driver.cArjun Shankar2021-04-071-2/+4
| | | | | | This allows the test to time out in case it hangs. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Update hppa libm-test-ulpsJohn David Anglin2021-04-061-25/+27
|
* m68: Fix build after 9acda61d94acAdhemerval Zanella2021-04-061-1/+0
| | | | The j0f/j1f/y0f/y1f now uses __inv_pio4.
* Update sv_SE to treate 'W' as a distinct character (Bug 25036)Sebastian Rasmussen2021-04-063-21/+13
| | | | | | | | | | | | The 13th edition of Svenska Akademiens ordlista lists 'W' as a distinct letter that sorts after 'V'. We adjust the sv_SE locale (and tests) to match this updated and "reformed" language change. This harmonizes us with CLDR 1.5.0 (2007) for sv_SE sorting of the letter 'W'. No regressions on x86_64, and locale sorting tests all pass. Co-authored-by: Carlos O'Donell <carlos@redhat.com>
* elf: Fix data race in _dl_name_match_p [BZ #21349]Maninder Singh2021-04-062-2/+20
| | | | | | | | | | | | | | | | | | | dlopen updates libname_list by writing to lastp->next, but concurrent reads in _dl_name_match_p were not synchronized when it was called without holding GL(dl_load_lock), which can happen during lazy symbol resolution. This patch fixes the race between _dl_name_match_p reading lastp->next and add_name_to_object writing to it. This could cause segfault on targets with weak memory order when lastp->next->name is read, which was observed on an arm system. Fixes bug 21349. (Code is from Maninder Singh, comments and description is from Szabolcs Nagy.) Co-authored-by: Vaneet Narang <v.narang@samsung.com> Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64: free tlsdesc data on dlclose [BZ #27403]Szabolcs Nagy2021-04-061-0/+27
| | | | | | | | DL_UNMAP_IS_SPECIAL and DL_UNMAP were not defined. The definitions are now copied from arm, since the same is needed on aarch64. The cleanup of tlsdesc data is handled by the custom _dl_unmap. Fixes bug 27403.
* ia64: Update ulpsAdhemerval Zanella2021-04-051-48/+49
| | | | | | Required after 9acda61d94acc "Fix the inaccuracy of j0f/j1f/y0f/y1f [BZ #14469, #14470, #14471, #14472]" and db3f7bb558 "math: Remove slow paths from asin and acos [BZ #15267]".
* ia64: Fix build after 9acda61d94acAdhemerval Zanella2021-04-052-4/+3
| | | | | The j0f/j1f/y0f/y1f now uses __inv_pio4 and call roundf (which turns to __roundf on ia64).
* i386: Update ulpsAdhemerval Zanella2021-04-052-37/+37
| | | | | Required after 9acda61d94acc "Fix the inaccuracy of j0f/j1f/y0f/y1f [BZ #14469, #14470, #14471, #14472]".
* Fix the inaccuracy of j0f/j1f/y0f/y1f [BZ #14469, #14470, #14471, #14472]Paul Zimmermann2021-04-0213-245/+1435
| | | | | | | | | | | | | | | | | | | | | | | For j0f/j1f/y0f/y1f, the largest error for all binary32 inputs is reduced to at most 9 ulps for all rounding modes. The new code is enabled only when there is a cancellation at the very end of the j0f/j1f/y0f/y1f computation, or for very large inputs, thus should not give any visible slowdown on average. Two different algorithms are used: * around the first 64 zeros of j0/j1/y0/y1, approximation polynomials of degree 3 are used, computed using the Sollya tool (https://www.sollya.org/) * for large inputs, an asymptotic formula from [1] is used [1] Fast and Accurate Bessel Function Computation, John Harrison, Proceedings of Arith 19, 2009. Inputs yielding the new largest errors are added to auto-libm-test-in, and ulps are regenerated for various targets (thanks Adhemerval Zanella). Tested on x86_64 with --disable-multi-arch and on powerpc64le-linux-gnu. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* x86-64: Fix ifdef indentation in strlen-evex.SSunil K Pandey2021-04-011-8/+8
| | | | | Fix some indentations of ifdef in file strlen-evex.S which are off by 1 and confusing to read.
* Update Nios II libm-test-ulps.Joseph Myers2021-04-011-6/+11
|
* socket: Add CFLAGS-accept.c and CFLAGS-connect.cAdhemerval Zanella2021-04-012-2/+2
| | | | | | | | The c59f716993 (accept) and 3ddf9bc185 (connect) added on io/Makefile instead of socket/Makefile. Checked on arm-linux-gnueabihf (where without the flags both the tst-cancelx4 and tst-cancelx5 fails).
* Update arm libm-tests-ulpsAdhemerval Zanella2021-04-011-1/+3
| | | | | Required after db3f7bb558 "math: Remove slow paths from asin and acos [BZ #15267]".
* support: Fix hurd build after bfddda2570331dAdhemerval Zanella2021-04-011-1/+1
|
* x86_64: Correct THREAD_SETMEM/THREAD_SETMEM_NC for movq [BZ #27591]H.J. Lu2021-04-013-2/+74
| | | | | | | | | | | | | | | | config/i386/constraints.md in GCC has (define_constraint "e" "32-bit signed integer constant, or a symbolic reference known to fit that range (for immediate operands in sign-extending x86-64 instructions)." (match_operand 0 "x86_64_immediate_operand")) Since movq takes a signed 32-bit immediate or a register source operand, use "er", instead of "nr"/"ir", constraint for 32-bit signed integer constant or register on movq. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* powerpc64le: Use ifunc for _Float128 functions also in libcAndreas Schwab2021-04-013-8/+17
| | | | | | This fixes missing definition of math functions in libc in a static link that are no longer built for libm after commit 4898d9712b ("Avoid adding duplicated symbols into static libraries").
* S390: Allow "v" constraint for long double math_opt_barrier and ↵Stefan Liebler2021-04-011-2/+19
| | | | | | | | | | | math_force_eval with GCC 11. Starting with GCC 11, long double values can also be processed in vector registers if build with -march >= z14. Then GCC defines the __LONG_DOUBLE_VX__ macro. FYI: GCC commit "IBM Z: Introduce __LONG_DOUBLE_VX__ macro" https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f47df2af313d2ce7f9149149010a142c2237beda
* io: fix spelling typo in diagnosticPaul Eggert2021-03-311-1/+1
|
* stdio-common/printf-prs.c: Reword commentAlejandro Colomar \(man-pages\)2021-03-311-2/+2
| | | | | | | | | | | 'this' can be understood as the current parameter, but in this case it is meaning the other one, the one holding the width/precission. 'it' better describes that parameter, differentiating it from the one corresponding to the current specifier. Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* io: Check at runtime if timestamp supports nanosecondsAdhemerval Zanella2021-03-313-9/+40
| | | | | | | | Now that non-LFS stat function is implemented on to on LFS, it will use statx when available. It allows to check for nanosecond timestamp if the kernel supports __NR_statx. Checked on s390-linux-gnu with 4.12.14 kernel.
* Fix conform linknamespace tests due to gnu_dev_makedevStefan Liebler2021-03-311-2/+2
| | | | | | | | | | | | | | | | | If building on s390 / i686 with -Os, various conformance tests are failing with e.g. conform/ISO/assert.h/linknamespace.out: [initial] __assert_fail -> [libc.a(assert.o)] __dcgettext -> [libc.a(dcgettext.o)] __dcigettext -> [libc.a(dcigettext.o)] __getcwd -> [libc.a(getcwd.o)] __fstatat64 -> [libc.a(fstatat64.o)] gnu_dev_makedev The usage of gnu_dev_makedev was recently introduced by usage of the makedev makro in commit: 5b980d4809913088729982865188b754939bcd39 linux: Use statx for MIPSn64 This patch is now linking against __gnu_dev_makedev as also done in commit: 8b4a118222c7ed41bc653943b542915946dff1dd Fix -Os gnu_dev_* linknamespace, localplt issues (bug 15105, bug 19463).
* manual: clarify that scanf %n supports type modifiersAlyssa Ross2021-03-301-5/+6
| | | | | | | | | | My initial reading of the %n documentation was that it didn't support type conversions, because it only mentioned int*. Corresponding man-pages patch: https://lore.kernel.org/linux-man/20210328215509.31666-1-hi@alyssa.is/ Reviewed-by: Arjun Shankar <arjun@redhat.com>
* Update sparc libm-tests-ulpsAdhemerval Zanella2021-03-301-1/+3
| | | | | Required after db3f7bb558 "math: Remove slow paths from asin and acos [BZ #15267]".
* libio: Update license on test caseSiddhesh Poyarekar2021-03-301-9/+10
| | | | | | | | | | About a decade ago, I accidentally wrote the GPLv3 license text on the test case when the rest of glibc source is LGPL v2.1 or later. As original author of the test (and there are no other legally significant changes to the test) I propose to update the license text to be consistent with the project. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Avoid adding duplicated symbols into static librariesSiddhesh Poyarekar2021-03-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Some math functions (such as __isnan*) are built into both libm and libc because they are needed in libc. The symbol gets exported from libc.so and not libm.so, because of which dynamic linking works fine; the symbols are always resolved from libc.so and libm.so uses its internal copy of the same function if needed. When linking statically though, the libm variants get used throughout because the symbols are exported in both archives and libm.a is searched first. This patch removes these duplicate objects from the libm.a archive so that programs always link to libc in both, the static and dynamic case. The difference this will cause is that libm uses of these functions will start using the libc versions in the !SHARED case. This is harmless at the moment because the objects are identical except for their names. Some of these duplicates could be removed from libm.so too, but I avoided that in the interest of retaining an internal reference if at all those functions get used within libm in future. Reviewed-by: Paul Zimmermann <Paul.Zimmermann@inria.fr>
* Move __isnanf128 to libc.soSiddhesh Poyarekar2021-03-3018-7/+39
| | | | | | | | All of the isnan functions are in libc.so due to printf_fp, so move __isnanf128 there too for consistency. Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@ascii.art.br> Reviewed-by: Florian Weimer <fweimer@redhat.com>
* fork.h: replace with register-atfork.hSamuel Thibault2021-03-2912-90/+10
| | | | | | | | | | | | | UNREGISTER_ATFORK is now defined for all ports in register-atfork.h, so most previous includes of fork.h actually only need register-atfork.h now, and cxa_finalize.c does not need an ifdef UNREGISTER_ATFORK any more. The nptl-specific fork generation counters can then go to pthreadP.h, and fork.h be removed. Checked on x86_64-linux-gnu and i686-gnu. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* x86-64: Use ZMM16-ZMM31 in AVX512 memmove family functionsH.J. Lu2021-03-293-19/+42
| | | | | | Update ifunc-memmove.h to select the function optimized with AVX512 instructions using ZMM16-ZMM31 registers to avoid RTM abort with usable AVX512VL since VZEROUPPER isn't needed at function exit.
* x86-64: Use ZMM16-ZMM31 in AVX512 memset family functionsH.J. Lu2021-03-294-24/+31
| | | | | | | Update ifunc-memset.h/ifunc-wmemset.h to select the function optimized with AVX512 instructions using ZMM16-ZMM31 registers to avoid RTM abort with usable AVX512VL and AVX512BW since VZEROUPPER isn't needed at function exit.
* x86: Add string/memory function tests in RTM regionH.J. Lu2021-03-2912-0/+618
| | | | | | | | At function exit, AVX optimized string/memory functions have VZEROUPPER which triggers RTM abort. When such functions are called inside a transactionally executing RTM region, RTM abort causes severe performance degradation. Add tests to verify that string/memory functions won't cause RTM abort in RTM region.
* x86-64: Add AVX optimized string/memory functions for RTMH.J. Lu2021-03-2952-248/+670
| | | | | | | | | | | | | | | | | Since VZEROUPPER triggers RTM abort while VZEROALL won't, select AVX optimized string/memory functions with xtest jz 1f vzeroall ret 1: vzeroupper ret at function exit on processors with usable RTM, but without 256-bit EVEX instructions to avoid VZEROUPPER inside a transactionally executing RTM region.
* x86-64: Add memcmp family functions with 256-bit EVEXH.J. Lu2021-03-295-4/+467
| | | | | | | Update ifunc-memcmp.h to select the function optimized with 256-bit EVEX instructions using YMM16-YMM31 registers to avoid RTM abort with usable AVX512VL, AVX512BW and MOVBE since VZEROUPPER isn't needed at function exit.
* x86-64: Add memset family functions with 256-bit EVEXH.J. Lu2021-03-296-14/+90
| | | | | | | Update ifunc-memset.h/ifunc-wmemset.h to select the function optimized with 256-bit EVEX instructions using YMM16-YMM31 registers to avoid RTM abort with usable AVX512VL and AVX512BW since VZEROUPPER isn't needed at function exit.
* x86-64: Add memmove family functions with 256-bit EVEXH.J. Lu2021-03-295-11/+104
| | | | | | Update ifunc-memmove.h to select the function optimized with 256-bit EVEX instructions using YMM16-YMM31 registers to avoid RTM abort with usable AVX512VL since VZEROUPPER isn't needed at function exit.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-05 20:48:15 +0000