Some kernels returns EINVAL for ioctl (PIDFD_GET_INFO) on pidfd descriptors. Checked on aarch64-linux-gnu with Linux 6.12. Reviewed-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Justin King <jcking@google.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Verify that the kernel side of the termios interface gets the various speed fields set according to our current canonicalization policy. [ v2.1: fix formatting - Adhemerval Netto ] [ v4: fix typo in patch description - Dan Horák ] Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (v2.1) Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Linux 7c7f55039b8d6 added HWCAP3_MTE_FAR and f620372209bfe added HWCAP3_MTE_STORE_ONLY.
The support for lock elision was already deprecated with glibc 2.42:
commit 77438db8cfa6ee66b3906230156bdae11c49a195
"Mark support for lock elision as deprecated."
See also discussions:
https://sourceware.org/pipermail/libc-alpha/2025-July/168492.html
This patch removes the architecture specific support for lock elision
for x86, powerpc and s390 by removing the elision-conf.h, elision-conf.c,
elision-lock.c, elision-timed.c, elision-unlock.c, elide.h, htm.h/hle.h files.
Those generic files are also removed.
The architecture specific structures are adjusted and the elision fields are
marked as unused. See struct_mutex.h files.
Furthermore in struct_rwlock.h, the leftover __rwelision was also removed.
Those were originally removed with commit 0377a7fde6dfcc078dda29a1225d7720a0931357
"nptl: Remove rwlock elision definitions"
and by chance reintroduced with commit 7df8af43ad1cd8ce527444de50bee6f35eebe071
"nptl: Add struct_rwlock.h"
The common code (e.g. the pthread_mutex-files) are changed back to the time
before lock elision was introduced with the x86-support:
- commit 1cdbe579482c07e9f4bb3baa4864da2d3e7eb837
"Add the low level infrastructure for pthreads lock elision with TSX"
- commit b023e4ca99f5e81f90d87d23cd267ef2abd2388c
"Add new internal mutex type flags for elision."
- commit 68cc29355f3334c7ad18f648ff9a6383a0916d23
"Add minimal test suite changes for elision enabled kernels"
- commit e8c659d74e011346785355eeef03b7fb6f533c61
"Add elision to pthread_mutex_{try,timed,un}lock"
- commit 49186d21ef2d87986bccaf0a7c45c48c91b265f3
"Disable elision for any pthread_mutexattr_settype call"
- commit 1717da59aed9612becd56aaa1249aac695af4c8a
"Add a configure option to enable lock elision and disable by default"
Elision is removed also from the tunables, the initialization part, the
pretty-printers and the manual.
Some extra handling in the testsuite is removed as well as the full tst-mutex10
testcase, which tested a race while enabling lock elision.
I've also searched the code for "elision", "elide", "transaction" and e.g.
cleaned some comments.
I've run the testsuite on x86_64 and s390x and run the build-many-glibcs.py
script.
Thanks to Sachin Monga, this patch is also tested on powerpc.
A NEWS entry also mentions the removal.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Factor out the internal kernel interface from termios_internal.h, so that it can be used in test code without causing breakage due to glibc internals used in headers. [ v3: fix Alpha build breakage ] Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
After getting more experience with the various broken direct-to-ioctl termios2 hacks using Fedora 43 beta, I have found a fair number of cases where the software would fail to set, or clear CIBAUD for non-split-speed operation. Thus it seems will help improve compatibility to clear the kernel-side version of c_cflag & CIBAUD (having the same meaning to the Linux kernel as the speed 0 has for cfsetibaud(), i.e. force the input speed to equal the output speed) for non-split-speed operation, rather than having it explicitly equal the output speed in CBAUD. When writing the code that went into glibc 2.42 I had considered this issue, and had to make an educated guess which way would be more likely to break fewer things. Unfortunately, it appears I guessed wrong. A third option would be to *always* set CIBAUD to __BOTHER, even for the standard baud rates. However, that is an even bigger departure from legacy behavior, whereas this variant mostly preserves current behavior in terms of under what conditions buggy utilities will continue to work. This change is in tcsetattr() rather than ___termios2_canonicalize_speeds(), as it should not be run for tcgetattr(); that would break split speed support for the legacy interface versions of cfgetispeed() and cfsetispeed(). [ v2: fixed comment style ] Resolves: BZ #33340 Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
It was missing from 3d52fd274e9.
The file was added with a GPL reference (but LGPL statement) in
commit 0d6bed71502f053fa702ccbb7dd4fa6741b2a0ed ("hppa: Add
____longjmp_check C implementation.").
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Collin Funk <collin.funk1@gmail.com>
As discussed in bug 28327, C23 changed the fromfp functions to return floating types instead of intmax_t / uintmax_t. (Although the motivation in N2548 was reducing the use of intmax_t in library interfaces, the new version does have the advantage of being able to specify arbitrary integer widths for e.g. assigning the result to a _BitInt, as well as being able to indicate an error case in-band with a NaN return.) As with other such changes from interfaces introduced in TS 18661, implement the new types as a replacement for the old ones, with the old functions remaining as compat symbols but not supported as an API. The test generator used for many of the tests is updated to handle both versions of the functions. Tested for x86_64 and x86, and with build-many-glibcs.py. Also tested tgmath tests for x86_64 with GCC 7 to make sure that the modified case for older compilers in <tgmath.h> does work. Also tested for powerpc64le to cover the ldbl-128ibm implementation and the other things that are handled differently for that configuration. The new tests fail for ibm128, but all the failures relate to incorrect signs of zero results and turn out to arise from bugs in the underlying roundl, ceill, truncl and floorl implementations that I've reported in bug 33623, rather than indicating any bug in the actual new implementation of the functions for that format. So given fixes for those functions (which shouldn't be hard, and of course should add to the tests for those functions rather than relying only on indirect testing via fromfp), the fromfp tests should start passing for ibm128 as well.