The shmlba.h file related to the LoongArch architecture was introduced
in commit 3eed5f3a1e to address the mismatch in the SHMLBA definition
between glibc and the kernel. See [1]. The SHMLBA definition was later
updated in commit d23b77953f5a. See [2]. Now, we adopt the definition
from the common layer.
[1]:
commit 3eed5f3a1e
Author: caiyinyu <caiyinyu@loongson.cn>
Date: Thu May 25 17:01:11 2023 +0800
LoongArch: Fix inconsistency in SHMLBA macro values between glibc and kernel
The LoongArch glibc was using the value of the SHMLBA macro from common code,
which is __getpagesize() (16k), but this was inconsistent with the value of
the SHMLBA macro in the kernel, which is SZ_64K (64k). This caused several
shmat-related tests in LTP (Linux Test Project) to fail. This commit fixes
the issue by ensuring that the glibc's SHMLBA macro value matches the value
used in the kernel like other architectures.
[2]:
commit d23b77953f5a4fbf94c05157b186aac2a247ae32
Author: Huacai Chen <chenhuacai@kernel.org>
Date: Wed Jan 17 12:43:08 2024 +0800
LoongArch: Change SHMLBA from SZ_64K to PAGE_SIZE
LoongArch has hardware page coloring for L1 Cache, so we don't have
cache aliases. But SFB (Store Fill Buffer) still has aliases. So we
define SHMLBA to SZ_64K previously. But there are losts of applications
use PAGE_SIZE rather than SHMLBA to mmap() file pages and shared pages.
Of course we can fix them one by one, but not easy.
On the other hand, we can simply disable SFB for 4KB page size to fix
cache alias (there will be performance decrease, but acceptable), and
in future we will fix SFB in hardware. So we can safely define SHMLBA to
PAGE_SIZE (use the generic shmparam.h) to make life easier.
Signed-off-by: caiyinyu <caiyinyu@loongson.cn>
Reported-by: lixing <lixing@loongson.cn>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This brings the si_codes listed in siginfo-consts.h up-to-date with
Linux v6.16's include/uapi/asm-generic/siginfo.h.
Tested on aarch64-linux-gnu and x86_64-linux-gnu.
Suggested-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
Linux 6.14 adds the new flag for uncached buffered IO on a filesystem
supporting it.
This caused two test failures as these tests expected the flag
0x00000080 is unused. Add the flag definition to fix these tests on
Linux >= 6.14:
FAIL: misc/tst-preadvwritev2
FAIL: misc/tst-preadvwritev64v2
The test failures were not detected in routine test suite runs because
normally we create the test file in /tmp, where a tmpfs is usually
mounted, and tmpfs does not support this flag. But it can be reproduced
with TMPDIR set to some directory in an ext4 file system.
Link: https://git.kernel.org/torvalds/c/af6505e5745b
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Vector variants of the new C23 exp2m1 & exp10m1 routines.
Note: Benchmark inputs for exp2m1 & exp10m1 are identical to exp2 & exp10
respectively, this also includes the floating point variations.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
This patch replaces _dl_stack_flags global variable by
_dl_stack_prot_flags.
The advantage is that any convertion from p_flags to final used mprotect
flags occurs at loading of p_flags. It avoids repeated spurious
convertions of _dl_stack_flags, for example in allocate_thread_stack.
This modification was suggested in:
https://sourceware.org/pipermail/libc-alpha/2025-March/165537.html
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
There is no need to use TESTL when checking the least-significant bit
with a TEST instruction. Use TESTB, which is three bytes shorter:
f6 44 24 04 01 testb $0x1,0x4(%esp)
vs:
f7 44 24 04 01 00 00 testl $0x1,0x4(%esp)
00
for the same effect.
No functional changes intended.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Cc: H.J.Lu <hjl.tools@gmail.com>
Cc: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
There is no need to use TESTL when checking the least-significant bit
with a TEST instruction. Use TESTB, which is three bytes shorter:
f6 44 24 f0 01 testb $0x1,-0x10(%rsp)
vs:
f7 44 24 f0 01 00 00 testl $0x1,-0x10(%rsp)
00
for the same effect.
No functional changes intended.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Cc: H.J.Lu <hjl.tools@gmail.com>
Cc: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
The copy_file_range system call seems to be the only one that can
return an off64_t value. Use FUSE to exercise this, without actually
creating such large files or copying any data. Due to FUSE protocol
limitations, only sizes up to UINT_MAX can be tested, but this is
sufficient to check for the presence of bug 33245.
The FUSE protocol limitations are raised here:
copy_file_range return value on FUSE
<https://lore.kernel.org/all/lhuh5ynl8z5.fsf@oldenburg.str.redhat.com/>
Reviewed-by: Sam James <sam@gentoo.org>
Reviewed-by: Collin Funk <collin.funk1@gmail.com>
This reverts commit 3d3572f590.
Reason for revert: TCGETS etc. work to some extent on at least
a subset of architectures, so there is no pressing need to force
applications off them. Removal of the macros breaks building
the sanitizers, impacting both GCC and LLVM.
Reviewed-by: Sam James <sam@gentoo.org>
The SFrame is well supported by x86 architecture since binutils 2.41.
Enable it to be used as default frame tracer.
Signed-off-by: Claudiu Zissulescu <claudiu.zissulescu-ianculescu@oracle.com>
Reviewed-by: DJ Delorie <dj@redhat.com>
Undefine TCGETS, TCGETS2, and related ioctl constants in the installed
headers. Extract the correct constants (using the kernel type
definitions) automatically from the UAPI headers. The kernel
constants are available under KERNEL_* names during the glibc build,
computed using assembler constant extraction mechanism.
Alpha may have to use TCGETS instead of TCGETS2 because TCTGETS2
became available in Linux 4.20 only. Introduce ARCH_TCGETS to make
this choice explict.
To support emulation on powerpc, glibc versions of the termios
constants are added to the emulation code in internal-ioctl.h.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The use of the termios2 ioctl interface is an implementation detail which
should not bleed into public headers. Remove the PowerPC version of
<bits/ioctls.h> and define the termios2 ioctl numbers in <termios_arch.h>
instead. Also remove the include check from there which is unneeded in an
internal header.
During early startup memcpy or memset must not be called since many targets
use ifuncs for them which won't be initialized yet. Security hardening may
use -ftrivial-auto-var-init=zero which inserts calls to memset. Redirect
memset to memset_generic by including dl-symbol-redir-ifunc.h in cpu-features.c.
This fixes BZ #33112.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Make '__close_nocancel_nostatus' standalone. This is a generic version
analogous to '__close_nocancel'. Platforms may choose to implement an
inline variant instead where the syscall invocation code sequence is
short enough to be beneficial over a function call.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Fix fallout from commit c181840c93 ("Consolidate non cancellable close
call") that caused '__close_nocancel_nostatus' to clobber 'errno' on a
close(2) failure, a 2.27 regression.
The problem came from a rewrite from 'close_not_cancel_no_status' to
'__close_nocancel_nostatus' switching from an inline implementation that
used INTERNAL_SYSCALL macro (which stays away from 'errno') to a call to
'__close_nocancel' function that uses INLINE_SYSCALL_CALL macro (which
does poke at 'errno').
Implement '__close_nocancel_nostatus' in terms of INTERNAL_SYSCALL_CALL
then, which leaves 'errno' intact.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Update tst-gnu2-tls2 tests to set XMM0...XMM7 to all 1s in malloc to
verify that XMM registers are preserved when _dl_tlsdesc_dynamic is
called by clearing vectors with zeroed XMM registers before
_dl_tlsdesc_dynamic and using these XMM registers to clear vectors
after _dl_tlsdesc_dynamic. This improves the BZ #31372 test.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Sam James <sam@gentoo.org>
There is no functional change in this patch.
We remove stores and loads to stack, return address signing, and redundant
CFI directives before and after call to __libc_arm_za_disable().
The __libc_arm_za_disable implementation follows special calling convention
that allows to avoid most of the operations that would be necessary for a
call to a normal function (see [1] for details).
First, we rely on __libc_arm_za_disable() not clobbering certain registers,
and we put return address into one of these registers. Now we don't need
to store it on stack, so we don't need to sign return address using PAC.
Second, as a result of the above, we don't need to update the CFI offset.
This patch provides small optimisation avoiding unnecessary store and load
on stack also simplifies assembly code and CFI directives.
[1]: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
No functional change here, just a small refactoring to simplify
using __alloc_gcs() for allocating shadow stacks.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Test that runs through a fairly large combination of the various
termios speed functions, for the new speed_t interface, for the old
speed_t interface (if enabled), and for the new baud_t interface.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The generic code has __ispeed and __ospeed; Linux has c_ispeed and
c_ospeed. Use an anonymous union member to allow both set of names on
all platforms.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Add an explicitly numeric interface for baudrate setting. For glibc,
this only announces what is a fair accompli, but this is a plausible
way forward for standardization, and may be possible to infill on
non-compliant systems. The POSIX committee has stated:
[https://www.austingroupbugs.net/view.php?id=1916#c7135]
A future version of this standard is expected to add at least
the following symbolic constants for use as values of objects
of type speed_t: B57600, B115200, B230400, B460800, and
B921600.
Implementations are encouraged to propose additional
interfaces which will make it possible to set and query a
wider range of speeds than just those enumerated by the
constants beginning with B. If a set of common interfaces
emerges between several implementations, a future version of
this standard will likely add those interfaces.
This is exactly that interface.
The use of the term "baud" is due to the need to have a term
contrasting "speed", and it is already well established as a legacy
term -- including in the names of the legacy Bxxx
constants. Futhermore, it *is* valid from the point of view that the
termios interface fundamentally emulates an RS-232 serial port as far
as the application software is concerned.
The documentation states that for the current version of glibc,
speed_t == baud_t, but explicitly declares that this may not be the
case in the future.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Now all platforms unconditionally use the "sane" definitions of the
termios baud constants. Unify them into a common file.
Note: I have made them explicitly unsigned to avoid problems with
compiler warnings for comparisons of unequal signedness or
similar. These constants were historically octal on most platforms,
and so unsigned by default.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Linux has supported arbitrary speeds and split speeds in the kernel
since 2008 on all platforms except Alpha (fixed in 2020), but glibc
was never updated to match. This is further complicated by POSIX uses
of macros for the cf[gs]et[io]speed interfaces, rather than plain
numbers, as it really ought to have.
On most platforms, the glibc ABI includes the c_[io]speed fields in
struct termios, but they are incorrectly used. On MIPS and SPARC, they
are entirely missing.
For backwards compatibility, the kernel will still use the legacy
speed fields unless they are set to BOTHER, and will use the legacy
output speed as the input speed if the latter is 0 (== B0). However,
the specific encoding used is visible to user space applications,
including ones other than the one running.
- SPARC and MIPS get a new struct termios, and tc[gs]etattr() is
versioned accordingly. However, the new struct termios is set to be
a strict extension of the old one, which means that cf* interfaces
other than the speed-related ones do not need versioning.
- The Bxxx constants are redefined as equivalent to their integer
values and the legacy Bxxx constants are renamed __Bxxx.
- cf[gs]et[io]speed() and cfsetspeed() are versioned accordingly.
- tcgetattr() and cfset[io]speed() are adjusted to always keep the
c_[io]speed fields correct (unlike earlier versions), but to
canonicalize the representation to ALSO configure the legacy fields
if a valid legacy representation exists.
- tcsetattr(), too, canonicalizes the representation in this way
before passing it to the kernel, to maximize compatibility with
older applications/tools.
- The old IBAUD0 hack is removed; it is no longer necessary since
even the legacy c_cflag baud rate fields have had separate input
values for a long time.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The powerpc architecture, only, emulates the termios ioctls using the
glibc termios structure. Export the real kernel ones as the termios2
interface; although the kernel doesn't call it termios2, it is exactly
the termios2 interface, and it avoids the namespace clash between the
emulated ioctls and the real kernel ioctls.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
In the kernel, these are <linux/sockios.h>. The differences between
<linux/sockios.h> and the copied data in <bits/ioctls.h> are minor;
mainly some #ifdefs, so try to use <linux/sockios.h> directly; it is
hopefully clean enough these days to use directly.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Replace local_isatty() inlined in libio with a proper function
__isatty_nostatus(). This allows simpler system-specific
implementations that don't need to touch errno at all.
Note: I left the prototype in include/unistd.h (the internal header
file.) It didn't much make sense to me to put it in a different header
(not-cancel.h), but perhaps someone can elucidate the need.
Add such an implementation for Linux, with a generic fallback.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
There is a prototype for an internal __tcsetattr() function in
include/termios.h, but tcsetattr without __ were still declared as the
actual functions.
Make this match the comment and make __tcsetattr() an internal
interface. This will be required to version struct termios for Linux on
MIPS and SPARC.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The third argument to __riscv_hwprobe is the size in bytes of the
cpu bitmask pointed to by the fourth argument, however in the access
attribute (read_only, 4, 3) it is used as an element count (i.e., the
number of unsigned longs that make up the bitmask), resulting in a
false compiler warning:
$ gcc -c hwprobe1.c
hwprobe1.c: In function 'main':
hwprobe1.c:15:11: warning: '__riscv_hwprobe' reading 1024 bytes from a region of size 128 [-Wstringop-overread]
15 | ret = __riscv_hwprobe (pairs, 1, sizeof(cpus), cpus, 0);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
hwprobe1.c:9:23: note: source object 'cpus' of size 128
9 | unsigned long int cpus[16];
| ^~~~
In file included from hwprobe1.c:1:
/usr/include/riscv64-linux-gnu/sys/hwprobe.h:66:12: note: in a call to function '__riscv_hwprobe' declared with attribute 'access (read_only, 4, 3)'
66 | extern int __riscv_hwprobe (struct riscv_hwprobe *__pairs, size_t __pair_count,
| ^~~~~~~~~~~~~~~
$
The documentation (https://docs.kernel.org/arch/riscv/hwprobe.html)
claims that the cpu bitmask has the type cpu_set_t *, which would be
consistent with other functions that take a cpu bitmask such as
sched_setaffinity and sched_getaffinity. It also uses the name
cpusetsize for the third argument, which is much more accurate than
cpu_count since it is a size in bytes and not a cpu count. The
(read_only, 4, 3) access attribute in the glibc prototype claims
that the cpu bitmask is only read, however when flags is
RISCV_HWPROBE_WHICH_CPUS it is both read and written.
Therefore, in the glibc prototype the type of the fourth argument is
changed to cpu_set_t * to match the documentation, the name of the
third argument is changed to cpusetsize as in the documentation, and the
incorrect access attribute that applies to these arguments is removed.
Almost all existing callers pass a null pointer for the fourth
argument, however a transparent union is introduced for compatibility
with callers that cast a pointer to the old argument type, and a
macro is introduced allowing callers the ability to distinguish
between the old and new prototype when needed.
The access attributes are being specified with __fortified_attr_access,
however this macro is for fortified functions; the regular
__attr_access macro is for non-fortified functions such as this one.
Using the incorrect macro results in no access checks at fortify level
3, because it is assumed that the fortified function will be doing the
checking. It is changed to use the correct macro so that the access
checks will work regardless of fortify level.
Also because __riscv_hwprobe is not a cancellation point, __THROW
is added, consistent with similar functions. (However, it is omitted
from the typedef because GCC does not accept it there.)
The __wur (warn_unused_result) attribute is helpful for functions that
cannot be used safely without checking the result, however code such
as the following does not require the result to be checked and should
not produce a warning:
struct riscv_hwprobe pair = { RISCV_HWPROBE_KEY_IMA_EXT_0, 0 };
__riscv_hwprobe (&pair, 1, 0, NULL, 0);
if (pair.value & RISCV_HWPROBE_EXT_ZBB) ...
Therefore this attribute is omitted.
The comment claiming that the second argument to the ifunc selector
is a pointer to the vDSO function is corrected. It is a pointer to
the regular glibc function (which returns errors as positive values),
not the vDSO function (which returns errors as negative values).
Fixes commit 426d0e1aa8 ("riscv: Add
Linux hwprobe syscall support").
Fixes: BZ #32932
Signed-off-by: Mark Harris <mark.hsj@gmail.com>
Signed-off-by: Mark Harris <mark.hsj@gmail.com>
Reviewed-by: Palmer Dabbelt <palmer@dabbelt.com>
Acked-by: Palmer Dabbelt <palmer@dabbelt.com>
Support for the SIOCGIFINDEX ioctl(2) Linux ABI (0x8933 command, called
SIOGIFINDEX in the API originally) was added with kernel version 2.1.14
for AF_INET6 sockets, followed by general support with version 2.1.22.
The Linux API was then updated by adding the current SIOCGIFINDEX name
with kernel version 2.1.68, back in Nov 1997.
All these kernel versions are well below our current default required
minimum of 3.2.0, let alone some platform higher version requirements.
Drop support for the absence of the SIOCGIFINDEX ioctl(2) in the API or
ABI, by removing arrangements for the ENOSYS error condition. Discard
the indirection from '__if_nameindex' to 'if_nameindex_netlink' and
adjust the implementation of '__if_nametoindex' accordingly for a better
code flow.
Linux 6.15 adds the new syscall open_tree_attr. Update
syscall-names.list and regenerate the arch-syscall.h headers with
build-many-glibcs.py update-syscalls.
Tested with build-many-glibcs.py.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Now we finally support modern GCC and binutils, it's time for a cleanup.
Use PAC and BTI instructions unconditionally and use proper assembler syntax.
Remove the PR target/94791 strip_pac workarounds for buggy GCCs. Remove the
PAC/BTI configure checks - always emit GNU property notes on assembly files.
Change cfi_window_save to the correct cfi_negate_ra_state unwind directive.
Reviewed-by: Matthieu Longo <matthieu.longo@arm.com>
Implement double and single precision variants of the C23 routine atan2pi
for both AdvSIMD and SVE.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Implement double and single precision variants of the C23 routine atanpi
for both AdvSIMD and SVE.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Implement double and single precision variants of the C23 routine asinpi
for both AdvSIMD and SVE.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Implement double and single precision variants of the C23 routine acospi
for both AdvSIMD and SVE.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
C23 adds various <math.h> function families originally defined in TS
18661-4. Add the rootn functions, which compute the Yth root of X for
integer Y (with a domain error if Y is 0, even if X is a NaN). The
integer exponent has type long long int in C23; it was intmax_t in TS
18661-4, and as with other interfaces changed after their initial
appearance in the TS, I don't think we need to support the original
version of the interface.
As with pown and compoundn, I strongly encourage searching for worst
cases for ulps error for these implementations (necessarily
non-exhaustively, given the size of the input space). I also expect a
custom implementation for a given format could be much faster as well
as more accurate, although the implementation is simpler than those
for pown and compoundn.
This completes adding to glibc those TS 18661-4 functions (ignoring
DFP) that are included in C23. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118592 regarding the C23
mathematical functions (not just the TS 18661-4 ones) missing built-in
functions in GCC, where such functions might usefully be added.
Tested for x86_64 and x86, and with build-many-glibcs.py.
