Fix multiple memory leaks in the locale program:
1. PUT (xstrdup (...)) leaks when tsearch finds a duplicate entry,
since tsearch returns the existing node and the newly allocated
string is orphaned. Introduce PUT_UNIQUE, which looks the name up
with GET first and only allocates when it is actually inserted.
2. String literals "POSIX" and "C" passed to PUT cannot be freed by
tdestroy. They now go through PUT_UNIQUE, which duplicates them,
so tdestroy (all_data, free) is safe.
3. Add tdestroy (all_data, free) at the end of write_locales and
write_charmaps to free the search trees.
4. Free dirents[cnt] entries in the scandir loop (only the dirents
array pointer was freed, not the individual entries).
5. Free alias_path allocated by argz_create_sep in write_locales.
Before this change "locale -a" leaked 74 bytes in 3 blocks directly
and 835 bytes in 49 blocks indirectly, and "locale -m" leaked 2190
bytes in 227 blocks. Both are valgrind-clean afterwards.
These leaks were reported by Arjun Shankar via GCC -fanalyzer
(OpenScanHub/Fedora).
Resolves: BZ #33972
Signed-off-by: Ruslan Valiyev <linuxoid@gmail.com>
Reviewed-by: Arjun Shankar <arjun@redhat.com>
logb (+-0) is a pole error: it returns -Inf and raises the
divide-by-zero exception, but it never set errno, even though glibc
defines math_errhandling to include MATH_ERRNO.
Set errno in the zero branch that already exists in every logb
implementation, instead of adding a w_logb wrapper; the
USE_LOGB*_BUILTIN paths have no such branch, so add one there. The
double and float versions use __math_divzero and __math_divzerof.
There is no long double equivalent, so those keep the explicit
division and use math_opt_barrier to stop the compiler from folding
it away.
The i386 fxtract implementations of logb and logbf cannot set errno,
and adding the error handling to the assembly is not worthwhile, so
they are removed in favour of the generic C ones. s_logbl.c moves to
sysdeps/x86/fpu, replacing the x86_64 copy that only included it.
The manual described logb (0) as returning +Inf without signalling,
which was wrong in both respects.
Tested on x86_64-linux-gnu.
Signed-off-by: Shamil Abdulaev <ashamil435@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
DO_DIVBYZERO placed __divbyzero in .gnu.linkonce.t.divbyzero so that,
when building the PIC libc.so, every divide routine's copy collapses to
one. .gnu.linkonce is a pre-comdat-group GNU convention that no current
toolchain emits and that upstream lld has declined to support in full
generality, since a linked-to section from outside a group is not valid
ELF and every non-GNU-as producer has used SHT_GROUP comdat groups
instead for 25+ years.
BZ #20543 tracked this migration across glibc; i386's PIC-thunk section
was converted, but alpha's divide-by-zero handler was missed. Switch it
to the same "axG",@progbits,<sym>,comdat idiom already used by the i386
and sparc PIC-thunk sections, so it is deduplicated via a real ELF group
rather than section-name matching.
Divide routines reach the handler via `beq Y, DIVBYZERO`, a 21-bit
word-displacement branch (+-4MB range). The old .gnu.linkonce.t.* name
put the section in the default linker script's last .text bucket,
guaranteeing it trailed all other code; .text.__divbyzero lands one
bucket earlier alongside other .text.* input sections, so "last in
.text" is no longer guaranteed (PIC libc.so only; libc.a keeps per-file
copies). Measured on an alpha-unknown-linux-gnu build, __divbyzero
landed a few hundred bytes from the end of a ~1.6MB .text. An
out-of-range branch would fail the link with "relocation truncated to
fit" rather than produce a silently broken libc.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
The tests-printers-out rule in Rules wraps $(PYTHON) through
$(test-wrapper-env). Unlike ordinary tests, which wrap a freshly built
target binary, this wraps python3, a build-host tool. When cross-testing
with test-wrapper set (e.g. via scripts/cross-test-ssh.sh) the whole
command is forwarded to the target; if the target lacks python3 the shell
returns 127 and evaluate-test.sh reports the six nptl pretty-printer
tests as FAIL instead of UNSUPPORTED.
scripts/test_printers_common.py already exits UNSUPPORTED (77) when its
dependencies are missing, but that is unreachable when python3 itself is
absent.
Guard the invocation with a "command -v" check so the recipe exits 77
(UNSUPPORTED) when python3 is not found. Native builds are unaffected,
as configure requires python3.
Signed-off-by: Hemanth Kumar M D <Hemanth.KumarMD@windriver.com>
Suggested-by: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This goes on top of the fix for CVE-2026-18374. The test runs the
reproducer from the bug report, plus "w,ccs=" and "w,ccs=,", and
expects NULL with errno set to EINVAL.
Signed-off-by: Shamil Abdulaev <ashamil435@gmail.com>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
When fopen() is called with a ,ccs= parameter whose value becomes empty
after strip(), the code must reject it with EINVAL instead of attempting
to use it. The original upstr() fallback could read past the ',' delimiter
and cause a heap buffer overflow.
The fix checks if the charset specification is empty after strip() and
returns EINVAL immediately, preventing the overflow and following the
approach described in BZ #34574.
CVE-2026-18374 - CVSS 4.9 (AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L)
Reported-by: AISLE in partnership with Red Hat
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Add smoke test verifying that getrusage returns non-negative user time and fails with invalid who value.
Co-authored-by: Frantisek Cech <fr.cech@proton.me>
Signed-off-by: Ondrej Marek <ondrejm4rek@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Commit 21841f0d56 ("PowerPC: Influence cpu/arch hwcap features via
GLIBC_TUNABLES") changed the INIT_ARCH() macro used by powerpc32/power4
and (via a one-line include) powerpc64 multiarch IFUNC resolvers to
read hwcap and hwcap2 through a direct
&GLRO(dl_powerpc_cpu_features)
reference, instead of the previous __GLRO() wrapper. The __GLRO() macro
performs a volatile NULL check on _rtld_global_ro, which matters because
IFUNC resolvers can run before _rtld_global_ro has been relocated for the
current library.
This regression triggers when a shared library's IFUNC symbol from libm
is resolved via BIND_NOW (full RELRO) before libm's own GOT is relocated:
the resolver's INIT_ARCH() then dereferences a NULL _rtld_global_ro and
segfaults at the hwcap load. The concrete failure seen was rsyslogd
crashing on startup on powerpc64 (e5500, BE) with
rsyslogd -> librsyslog -> libfastjson -> modf() IFUNC in libm
when libfastjson lacked a DT_NEEDED on libm, so libm was relocated after
libfastjson's IFUNC resolvers ran.
Restore the __GLRO()-based access for both hwcap and hwcap2, matching
the pre-2.41 behaviour and how use_cached_memopt is already read in the
same macro. This is a no-op once _rtld_global_ro is fully initialised
and simply reinstates the early-startup NULL guard.
Add a regression test (ppc64 only; ppc32 has additional early-startup
constraints that make the same test infeasible there). The module is
linked with -z,now and intentionally has no DT_NEEDED on libm, so the
IFUNC resolver for modf() runs before libm is fully relocated.
Signed-off-by: Michael Pfeifroth <micpf@westermo.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The reference implementation renders the a and A conversions by
splitting the value into a significand of the width the type has and a
power of two. That presumes the type is a single binary floating-point
format. The IBM extended format is a pair of doubles instead, whose
combined significand has no fixed width and whose subnormals are those
of the low double rather than of the type, so what glibc produces for it
does not follow from PREC and MINEXP: LDBL_MAX comes out as
0x1.fffffffffffff7ffffffffffff8p+1023 with twenty-eight fractional
digits where the value has at most twenty-six worth of significand, and
LDBL_TRUE_MIN as 0x0.0000000000001p-1022, which is the smallest
subnormal double and nowhere near LDBL_MIN_EXP.
The remaining conversions are unaffected, as they work from the value
rather than from a decomposition of it, and were verified to be.
Add an UNSUPPORTED_CONVS definition to the skeleton for conversions that
cannot be modeled for the type at hand, and set it to the a and A pair
where long double has that format, the generator then producing no
records and an unsupported status which the long double wrapper reports.
Tested on x86_64-linux-gnu and powerpc64le-linux-gnu, where all 672
results pass, and with the long double conversions forced to the IBM
extended format, where the a and A ones report unsupported and the rest
continue to pass.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The reference implementation used to verify the a and A conversions
assumed the value it was given was normal, splitting it into a
significand of the full width and an exponent. That is not true below
the smallest normal value, where the exponent can go no lower and the
significand loses bits from the top instead, which is what makes the
leading hexadecimal digit of a subnormal come out as zero. Given a
subnormal it would have produced a normalized result such as 0x1p-1070
where we print 0x0.000000000001p-1022.
Telling the two apart needs the minimum exponent for the type, which was
not among the data the test program supplies, so add it as a MINEXP
definition reported in a record of its own next to the working
precision. Then stop normalizing once that exponent is reached, and pad
the digits produced on the left, as there are no longer enough of them
to fill the field on their own. The remaining conversions are
unaffected: they work from the value itself and never needed it
decomposed.
How far the exponent has to be shifted to sit after the significand
depends on the working precision, so hold MINEXP as reported and combine
the two only once a value is due to be converted, rather than requiring
the records to arrive in a particular order. Where no MINEXP record
arrives the type has no subnormals and no clamping is applied.
None of the values iterated over were subnormal, so this could not be
observed. Add DBL_TRUE_MIN and LDBL_TRUE_MIN to cover it, which also
exercises the smallest exponent with the remaining conversions. How
many bits the leading hexadecimal digit holds varies with the type, one
for a 53 bit significand and four for a 64 bit one, so both are needed:
the wider case lands on a different exponent than the minimum for the
type, with LDBL_TRUE_MIN coming out as 0x0.000000000000001p-16385 rather
than at the p-16382 that the leading digit of a normal value would sit
at. One sign is enough for either, as nothing in the sign handling
depends on the value being subnormal, and the records these produce are
among the most expensive in the test suite.
Tested on x86_64-linux-gnu, where all 672 results pass.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The a and A conversions were left out when the formatted printf output
tests were added, because gawk produces output that differs from ours,
using insufficient precision where none has been given and choosing a
different exponent otherwise. Verification no longer goes through AWK,
and computing the reference output directly makes them straightforward,
so cover them now.
The significand is written out as it stands, which means the leading
hexadecimal digit holds whatever bits are left over once the remaining
ones are grouped into whole digits: one bit for a 53 bit significand, so
the digit is 1, and four for a 64 bit one, so it runs from 8 to f.
Rounding to a requested precision can carry out of that digit, in which
case the result is re-expressed with one digit fewer and the exponent
raised by four rather than the integer part being widened. The 0x
prefix precedes any '0' flag padding, as it does for the integer
hexadecimal conversions.
Unlike the remaining floating-point conversions these produce different
digits for an omitted precision than for one of 6, so key the memoized
digits on the precision as given rather than as defaulted.
Tested on x86_64-linux-gnu, where all 672 results pass.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The b and B conversions were left out when the formatted printf output
tests were added, because gawk does not handle them at all.
Verification no longer goes through AWK, so cover them now.
They follow the existing integer conversions, with the alternative form
producing the 0b or 0B prefix for a nonzero value.
Note that B was listed for neither the '#' and '0' flags nor precision,
so add it to those lists next to b, as otherwise most of its records
would never be produced.
Tested on x86_64-linux-gnu, where all 576 results pass.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The formatted printf output tests verify their records against GNU AWK,
relying on it to provide an implementation of format processing that is
independent from ours.
AWK has to run in the bignum mode for the floating-point conversions,
because otherwise it uses the system sprintf(3) internally and we end up
verifying our code against itself. That in turn makes gawk compiled
with MPFR support a requirement for testing the library at all. Beyond
that gawk mishandles a number of cases which the AWK script then has to
undo by hand: the extraneous leading 0 produced for the alternative form
with the octal conversion, the 0 produced where no characters are
expected for the hexadecimal conversions, the missing + and space
characters for a zero value with the precision of zero, and a collection
of sign, flag and field width anomalies for Inf and NaN values. Each
such workaround suppresses whatever we might get wrong in the same
place. The a, A, b, and B conversions cannot be verified at all,
because gawk either does not handle them or produces different output.
Replace the AWK script with an equivalent one written in Python, which
is already a requirement for building the library. Rather than calling
into any formatting routine it computes the reference output directly,
using exact integer and rational arithmetic. Working exactly means the
result does not depend on the range or precision of any host
floating-point type, so the wider types are handled without
arbitrary-precision arithmetic having to be built into the interpreter,
and none of the workarounds listed above are needed: the corner cases
they cover are computed correctly. The same property removes the reason
the a, A, b, and B conversions had to be left out; adding them is left
for the commits that follow. Rendered digits are memoized per value,
without which the exact arithmetic makes the long double conversions
slower than AWK.
As the capability probes only ever detected gawk build options, they go
away along with the unsupported status they could produce, so the f and
F conversions are now always verified rather than silently skipped where
gawk was built without them. Drop the corresponding note on MPFR from
the installation instructions.
Tested on x86_64-linux-gnu, where all 576 results continue to pass.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The file does not actually show up as reachable until getting linkat'ed,
which makes it 000 with the current ext2fs, but better make the filesystem
record proper mode anyway.
As documented by posix & linux, if the real ID is set or the effective ID is
set to a value not equal to the previous real ID, the saved ID shall be set
to the new effective ID.
The strto* declarations in stdlib.h are marked __nonnull, but the
corresponding declarations in inttypes.h and wchar.h are not. Add the
attribute there as well, covering the __REDIRECT and __isoc23_* variants
and the _l forms, matching stdlib.h.
Signed-off-by: Shamil Abdulaev <ashamil435@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
For AT_SECURE programs the loader honors $ORIGIN in DT_RPATH only when the
expansion is rooted in a trusted directory, but it validated the lexically
normalized path while opening the raw expansion. As "a/b/../c" only names
"a/c" when "b" is not a symlink, an attacker who controls a component of
$ORIGIN -- e.g. by hard-linking the setuid binary into an attacker-owned
directory -- can make the opened path escape the trusted directory even
though the check passed, loading an attacker-controlled object.
Normalize the expansion in place and open that, so the path that is opened
is exactly the path that was validated. _dl_normalize_path rewrites the
string in place without ever advancing its write cursor past its read
cursor or appending, so it stays within the original storage.
Add elf/tst-origin-secure as a regression test.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
The reference to MAP_NORESERVE and /proc/sys/vm/overcommit_memory was
moved from proc(5) to proc_sys(5) in man-pages commit bfc1299e7 (proc.5,
proc_sys.5: Split /proc/sys/ from proc(5), 2023-08-15). It was
subsequently moved to proc_sys_vm(5) in man-pages commit
b06cd070f (proc_sys.5, proc_sys_vm.5: Split /proc/sys/vm/ from
proc_sys(5), 2023-09-30).
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Largely auto-generated, using glibc-specific interfaces, and
following (manually-written) sysdeps/pthread/tst-robust12.c.
Assisted-by: LLM
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This allows priority-protect tests to be regular tests. They
exit with EXIT_UNSUPPORTED if the process does not have sufficient
privileges.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Also fix __pthread_tpp_change_priority to undo changes to the priomap
array if any of the scheduler system calls fail.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
For some error scenarios, the robust list head is left pointed at
the mutex after the return. This can cause the kernel to update
the mutex lock field after it has been reallocated for something
else.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The non-PI case already does this:
/* Work around the fact that the kernel rejects negative timeout
values despite them being valid. */
if (__glibc_unlikely (abstime->tv_sec < 0))
return ETIMEDOUT;
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The g and G conversions choose between the f and e styles according to
the exponent the value has once rounded to the requested number of
significant digits. Where the value is small enough for the f style but
rounding then carries into a new decade, printf_fp rewrites the digits
it has already produced into the e style, recomputing along the way how
many fractional digits the leading digit now leaves room for.
FRACDIG_MIN, which the alternative form sets to the number of fractional
digits that have to be retained rather than stripped, was left behind at
the value computed for the f style. Where the value filled the whole
integer part that is zero, so all the fractional digits were then
stripped from a result the '#' flag requires to keep them:
printf ("%#.2g", 99.9) gave "1.e+02" rather than "1.0e+02"
printf ("%#g", 999999.9) gave "1.e+06" rather than "1.00000e+06"
Update FRACDIG_MIN along with FRACDIG_MAX. Without the alternative form
nothing retains trailing zeros, so the outcome is unchanged there.
None of the values the conversion tests iterate over round this way, so
add one that does at a precision they cover.
Tested on x86_64-linux-gnu.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
HUGE_WIDTH is chosen so that none of the strings produced are truncated,
which for the floating-point types means every record it takes part in
carries hundreds or thousands of digits. Those records dominate the
cost of this whole family of tests: for the long double conversions they
are 99% of the bytes produced, and the long double targets alone account
for 92% of the time the tests take.
The digits being checked are produced by the same conversion code
whichever of the printf family of functions is used; what differs
between the twelve of them is the sink the result is written to, which
the smaller widths cover already.
Iterate over HUGE_WIDTH for a single function then, chosen as printf,
and let the remaining eleven stop at MID_WIDTH. This applies to the
double and long double conversions only; for the other types
full-precision output is short and costs nothing, so they keep iterating
over it as before.
Together with the switch to verifying in Python this takes the tests
from 935s to 375s of processor time on x86_64-linux-gnu, with all 576
results continuing to pass. What remains is mostly intrinsic: the f and
F conversions print the whole integer part regardless of the precision
requested, so LDBL_MAX runs to some 4932 digits even at MID_WIDTH.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Since af34b1376a ("elf: Initialize static TLS before relocation
processing", BZ 34164) dropped the 'defer-if-not-relocated' branch in
_dl_try_allocate_static_tls, nothing sets l_need_tls_init any more. The
second pass in update_tls_slotinfo, guarded by l_need_tls_init, is
therefore dead: its _dl_update_slotinfo / _dl_init_static_tls calls never
run, and the static TLS image is initialised inline during relocation (IE
model) or lazily on first dynamic-TLS access instead.
Remove the dead loop, the now write-only l_need_tls_init field and its
clear in _dl_allocate_tls_init. No functional change.
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu.
I also run the elf tests on armv7-a, alpha, loongarch64, mips64le,
powerpc, riscv, and s390x using qemu system.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
The initial static-pie support (commit 9d7a3741c9) reused
ld.so ELF parsing logic, even though RPATH/RUNPATH should not appear
in the static-pie bootstrap. With static PIE, RPATH/RUNPATH on the
loader typically indicates a toolchain misconfiguration. However,
for static PIE, the presence of RPATH/RUNPATH has no impact because
these binaries do not use dynamic linking at runtime.
Fully static binaries have no dynamic section, so RPATH/RUNPATH can not
appear there at all; for static PIE the only consumer is dlopen. If
static dlopen support is ever removed, this change becomes a no-op.
This change also simplifies elf_get_dynamic_info and removes a
difference between dynamic and static binaries, along with the now
unused STATIC_PIE_BOOTSTRAP.
Tested on aarch64-linux-gnu and x86_64-linux-gnu.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
The BZ#33326 testcase triggers an assertion during process startup,
which results in a segmentation fault instead of an error message
and process termination with a SIGABRT. The assert issues
__libc_message_impl, which in turn might call string functions
depending on the ABI (strchrnul, strlen, memcpy/mempcpy), system
calls (writev and mmap), and finally the abort call.
The dl-symbol-redir-ifunc.h is also expanded to cover strchrnul on
x86_64, s390, powerpc64 (both endianness) and loongarch, mempcpy on
powerpc64be, and memcpy on aarch64. On s390 the redirection is only
issued if the ifunc variant is built, since strchrnul-c.c only renames
the C implementation to STRCHRNUL_DEFAULT when HAVE_STRCHRNUL_IFUNC is
set.
The buffer that backs up the assert message is now allocated through
_dl_mmap, which issues the syscall directly instead of calling __mmap
(setting errno on failure requires the thread pointer).
The abort call now issues __raise_direct instead of raise (the Hurd
port aliases __raise_direct to raise).
On i386, syscalls should not use the vDSO during program startup because
the thread pointer is not yet initialized. This requires __raise_direct,
_dl_writev, and _dl_mmap to be built with I386_USE_SYSENTER set to 0.
Creating a test case is challenging. For static-pie, the assert is only
called for ill-formed ELF files on elf_get_dynamic_info and by some targets
on ELF_DYNAMIC_RELOCATE (although not all targets use assert in their
dl-machine.h). Some targets also issue __libc_fatal on ARCH_SETUP_IREL,
but also only for ill-formatted ELF files.
The test employs a different strategy and overrides the __tunables_init
symbol, which is invoked immediately before self-relocation and TLS setup.
The test is built with -Wl,-z,muldefs to avoid linker issues.
I checked on aarch64, x86_64, i686, s390x (qemu), sparc (qemu),
mips64el (qemu), armhf, riscv, and powerpc.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
And change _dl_writev to return a negative errno in case of failure.
This keeps the required semantics for not setting errno on failure
and allows removing the Linux libc_fatal.c implementation.
It also makes it simple to use the writev syscall during process
startup, especially on i386, where it requires disabling vDSO.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
.. and openat64.
Linux 7.2 (31cf44efa6df72a524b40adefb80539f3a4e13ba) allows openat, openat2
to take a NULL path with the new O_EMPTYPATH flag, so the nonnull attribute
is no longer sound. Drop it.
Bug: https://sourceware.org/PR34313
Reviewed-by: Paul Eggert <eggert@cs.ucla.edu>
Since Linux 6.11, AT_EMPTY_PATH can be used for a NULL path argument, so
the nonnull attribute is no longer sound. Drop it.
This bug was worked around in gnulib's 6db27b4dd36eda618db20e997ff56bbed7fce3cb.
See also 55618e1396 which fixed fstatat
in glibc.
Bug: https://sourceware.org/PR34313
Reviewed-by: Paul Eggert <eggert@cs.ucla.edu>
This makes the tests the same in both places. The changes in Gnulib
brought in by this patch also silence -Woverflow when using gcc 16.1.1
on i686.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch changes the behavior of pthread_mutex_lock in case of
non-trivial deadlock. The user-space code doesn't detect the case
where two or more threads would mutually deadlock each other, but the
Linux kernel can. NPTL's previous behavior, if the syscall returns
EDEADLK, was to run into an assertion.
With this patch:
- For error-checking PI mutexes; the error code will be propagated to
the caller who might then, at its own discretion and with knowledge
about the application-level logic, use it to attempt resolving the
situation gracefully or terminate the process after all. Since
error-checking mutexes are specified to possibly return EDEADLK,
and the only reason to use them in the first place is for the sake
of these additional error checks, any calling code failing to check
the return code in this case may legitimately be considered broken
already.
- For recursive mutexes; the thread will actually deadlock instead of
failing the assertion. It has been discussed (see below) that this
might be more conservative as, unfortunately, lots of existing code
might be guilty of not always checking the return code. So
returning at all in this case might cause (arguably questionable)
code to continue executing undefined behavior by falsely assuming
that the thread successfully acquired a lock, which it didn't.
- For all other mutex types; the behavior is not changed. They will
continue to actually deadlock the calling thread as they did prior
to this patch.
A new test is added to assert the expected behavior of all mutex
types.
Since POSIX doesn't seem to mandate any particular behavior for this situation,
and no existing code should have a dependency of running into an assertion,
changing this behavior to what is presumably the most useful one seems to be
justified.
The previous (design) discussions can be seen here:
https://sourceware.org/pipermail/libc-alpha/2025-December/173431.htmlhttps://sourceware.org/pipermail/libc-alpha/2026-April/176406.html
Signed-off-by: Moritz Klammler <moritz.klammler.ext@siemens.com>
Commit a2b0ff98a0 added __attribute_optimization_barrier__ and converted the
users of __attribute__ ((noinline, noclone)) to it, so that Clang, which does
not implement noclone, gets optnone instead of an unknown-attribute warning
that is an error under -Werror.
Twelve users were missed, all of them in code that a plain x86_64 build never
preprocesses, which is why they survived the sweep:
- libio/tst-stderr-compat.c is inside
#if TEST_COMPAT (libc, GLIBC_2_0, GLIBC_2_1), so it is compiled only on
ports that still have GLIBC_2.0 compat symbols -- i686 and alpha among
them, but not x86_64. Building it with Clang fails.
- The eleven sysdeps/x86_64/x32/tst-size_t-*.c tests are built only for the
x32 ABI.
No functional change for GCC, which still gets noinline and noclone.
Checked that both shapes -- the weak function in libio and the static function
in the x32 tests -- compile with GCC and with Clang after the change, and that
the pre-change shape is an error under Clang with -Werror.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The fts and fts64 interfaces can share an implementation only when
both their offset and inode types have matching layouts.
The existing conditions check only whether off_t and off64_t match.
On Alpha, these types match, but ino_t and ino64_t differ.
Consequently, FTSENT and FTSENT64 have different layouts.
The ordinary fts implementation is therefore omitted on Alpha, and
the ordinary fts symbols are instead aliased to the fts64
implementation. This causes the ordinary interface to operate on an
incompatible FTSENT64 layout and corrupts traversal state.
Build the ordinary implementation unless both the offset and inode
types match. Likewise, alias the ordinary symbols to the fts64
implementation only when both types match.
An audit of the bits/typesizes.h implementations shows that Alpha is
the only ABI where __OFF_T_MATCHES_OFF64_T is defined but
__INO_T_MATCHES_INO64_T is not. Therefore, this changes the
implementation selection only on Alpha.
This fixes io/tst-fts, io/tst-fts-bz22944, and io/tst-fts-newflags on
Alpha.
Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
In a few places, we weren't exiting w/ 77 when skipping. Fix that by using
our standard macro for it.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Ruslan Valiyev
Shamil Abdulaev
Matt Turner
Hemanth Kumar M D
Florian Weimer
Dongkyun Son
Ondrej MarekandFrantisek Cech
Michael Pfeifroth
Samuel Thibault
Adhemerval Zanella
Yury Khrustalev
Collin Funk
Jiayuan Chen
Sam James
Moritz Klammler
Rolf Eike Beer
Magnus Lindholm