libc: Enforce lock-free atomic_flag and C23-safe initialisation
Select the `atomic_flag` backing type according to the C standard
requirements that `atomic_flag` operations be lock-free.
C11 §7.17.1.5 defines `atomic_flag` as:
> a structure type representing a lock-free, primitive atomic flag
and §7.17.8.2 further requires:
> Operations on an object of type atomic_flag shall be lock free
Therefore:
- Prefer `atomic_bool` when `ATOMIC_BOOL_LOCK_FREE == 2`
- Fall back to `atomic_uchar` when `ATOMIC_CHAR_LOCK_FREE == 2`
- Trigger a translation failure if neither type is lock-free
[13 lines not shown]
libc: Fix GCC pointer semantics for atomic_fetch_add/sub
Correct the GCC implementation of `atomic_fetch_add_explicit()`
and `atomic_fetch_sub_explicit()` for atomic pointer types.
The previous implementation passed the operand directly to the
builtins. For pointer objects, this could result in raw byte-wise
address arithmetic rather than the required C atomic pointer
semantics, where the operand is interpreted as a `ptrdiff_t`
element count.
As a result, operations such as `atomic_fetch_sub_explicit(&p, 2, ...)`
could produce an incorrect post-operation pointer value.
Fix this by applying pointer scaling in the GCC path before invoking
the builtin, mirroring the existing legacy fallback implementation.
Pointer operands are now scaled by the size of the pointed-to type,
while integer atomic behaviour remains unchanged.
[3 lines not shown]
libc: Fix atomic_init for GCC atomic objects
Add a dedicated `__GNUC_ATOMICS` path that initialises via
`atomic_store_explicit(obj, value, memory_order_relaxed)`.
This ensures the required initialisation semantics without
assuming any particular object representation.
Previously, `atomic_init` on GCC fell through to the legacy
`__val` member path intended only for old struct-backed
atomic objects. For current atomic objects, this caused the
following compilation error:
> error: request for member '__val' in something not a
structure or union
As a result, valid code such as `atomic_init(&x, 1)` failed
to compile when using GCC.
[6 lines not shown]
libc: Reorder atomic operations to match ISO C standard
Reorder definitions of specified generic operations on atomic types
so they follow the sequence in ISO/IEC 9899:2024 §7.17.7:
1. `atomic_store`
2. `atomic_load`
3. `atomic_exchange`
4. `atomic_compare_exchange`
5. `atomic_fetch`
This aligns the header layout with the standard, making it easier
to cross-check against the normative text and maintain consistency
with the rest of the header.
The behaviour of the macros remains unchanged; this is purely a
reorganisation and documentation improvement.
Signed-off-by: Faraz Vahedi <kfv at kfv.io>
[2 lines not shown]
libc: Add missing kill_dependency macro
Add `kill_dependency` as specified by C11 §7.17.3.1.
The macro is required to break dependency chains in
expressions without affecting the value.
No functional impact beyond providing the required,
value-preserving definition.
Signed-off-by: Faraz Vahedi <kfv at kfv.io>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/2185
rtw88: Fix typo in portability glue
Fix typo in if statement for compiling rtw88 against a Linux target.
Signed-off-by: Lambert Lim <lambert at sanesecurityguy.com>
Reviewed by: imp,ziaee
Pull Request: https://github.com/freebsd/freebsd-src/pull/2262
libc: Restrict ATOMIC_VAR_INIT for C23 conformance
Omit `ATOMIC_VAR_INIT` when targeting C23, where it has been removed.
Retain it for earlier C standards and for C++ (as it still remains in
C++23, albeit marked as deprecated since C17 and C++20.)
Also separate `atomic_init` definitions from `ATOMIC_VAR_INIT` to
avoid coupling with a deprecated initialisation mechanism.
No functional change intended for `atomic_init`; this is purely a
conformance and cleanup adjustment.
Signed-off-by: Faraz Vahedi <kfv at kfv.io>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/2185
libc: Reorganise memory_order enumeration constants
Place the `memory_order` enumeration constants alongside the corresponding
typedef under the §7.17.3 heading.
The previous layout separated the fallback constant definitions from the
enum, which could obscure their relationship. These fallbacks exist only
to provide values when the compiler does not supply the builtins.
The removed comment encoded implementation-specific assumptions about
compiler-provided definitions and implied a relationship between Clang/GCC
macros and fallback values. In practice, the fallback definitions exist
solely to ensure the enumerators are defined when compiler intrinsics are
absent, and do not depend on any particular numeric mapping.
No functional change; this is a mere structural and clarity improvement.
Signed-off-by: Faraz Vahedi <kfv at kfv.io>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/2185
powerpc64le: switch long double to IEEE binary128
Change powerpc64le's long double from 64-bit double to IEEE 754
binary128 (quad, 113-bit mantissa), matching aarch64 and riscv64.
Gated on FreeBSD 16 and powerpc64le only.
Differential Revision: https://reviews.freebsd.org/D57388
Reviewed by: adrian
Relnotes: yes
Update dirdpes.mk et al
Update to latest dirdeps related makefiles.
dirdeps.mk tweaks useful for universe among other corner cases.
also additional filtering for bogus paths ending in /
gendirdeps.mk allow more debugging
also additional filtering for bogus paths ending in /
install-new.mk fix bug when isPOSIX_SHELL is true
meta2deps.?? handle file names with spaces by ignoring them
Reviewed by: stevek
Differential Revision: https://reviews.freebsd.org/D57683
imgact_elf.c indicate that interpreter is an interpreter
Use a value that do_execve will ignore since there's nothing there to do.
With this we can set the 'indirect' flag on rtld, to prevent direct execution
being used to bypass the 'indirect' flag on python3:
root at vuefi:~ # /libexec/ld-elf32.so.1 /usr/bin/python3 -c 'print("pwned")'
pwned
root at vuefi:~ # veriexec -z enforce
root at vuefi:~ # /libexec/ld-elf32.so.1 /usr/bin/python3 -c 'print("pwned")'
/libexec/ld-elf32.so.1: Operation not permitted.
root at vuefi:~ #
load_file seems missnamed since it is only used by load_interp
so rename it to load_interp_file.
Reviewed by: imp
Sponsored by: Hewlett Packard Enterprise Development LP
Differential Revision: https://reviews.freebsd.org/D57649
thunderbolt.4: Explain what driver does in manpage
Reviewed by: ziaee, ngie
Approved by: ziaee
Fixes: 2f7a796b590e ("thunderbolt.4: Initial manual for HW Relnotes")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57668
jail: call PR_METHOD_ATTACH again (with old jail) if the first call fails
jail_attach lets modules do attachment-specific work by calling
osd_jail_call(PR_METHOD_ATTACH). If one of the modules returns an
error, the call needs to be repeated with the thread's current prison,
so possible earlier modules and undo any changes they may have made.
MFC after: 5 days
firewire: extract shared helpers from fwe and fwip
Add fw_net.h with common inline helpers used by both if_fwe and
if_fwip: ISO chunk init, TX xfer allocation, xferlist free,
send queue drain, and DEVICE_POLLING ioctl handling.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D57615
sys/cdefs.h: Introduce __maybe_unused attribute
The __maybe_unused attribute should be used for variables which may or
may not be used, such as when their only use is in an assertion. This
attribute is functionally identical to __unused, suppressing compiler
warnings for particular variable if it remains unused.
Reviewed by: Minsoo Choo <minsoo at minsoo.io>, imp
Differential Revision: https://reviews.freebsd.org/D56517
(cherry picked from commit 84a95741805d84f0074a34d61b93ccf86f422cf3)
rc.d/routing: Silence errors for loopback routes
_loopback entry in `static_routes` ensures a loopback route
exists in all routing tables.
However, loopback routes may already be added by the kernel.
Therefore, re-adding them triggers an `EEXIST` error on every boot.
This change suppresses those harmless errors.
PR: 259553
MFC after: 1 week
Reviewed by: glebius, jlduran, markj
Differential Revision: https://reviews.freebsd.org/D57470
(cherry picked from commit 9f80c8b90bdaa8ffac887a8c478a16c84d74a87b)
tests: Add pjdfstest integration
Use ATF to wrap the new reimplementation of pjdfstest that came out of
GSOC 2022, now available in the ports tree as filesystems/pjdfstest.
So far I added tests for UFS (with several different option
combinations), tmpfs and ZFS, plus ZFS+nullfs. All of these create a
memory disk, initialize the filesystem, and point the pjdfstest
executable at it.
In the future it would be good to add tests for at least NFS and p9fs.
Reviewed by: asomers
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D56605
ctermid(3): Fix return values section
ctermid() doesn't, and has never, set errno.
While here, add ctermid_r to the name section and align the parameter
name in the source file.
Reviewed by: bnovkov
Approved by: bnovkov
MFC after: 3 days
Obtained from: https://github.com/apple-oss-distributions/libc
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D57396
uart: Add support for the Intel XScale controller
The ns8250 driver avoids clearing IER bit 0x10 to account for the
split "receiver time-out interrupt enable" bit, but it never sets
it in `ier_rxbits` even though a comment in `ns8250_init` implies so.
Fix this by setting `IER_RXTMOUT` if we've matched an XScale uart.
Differential Revision: https://reviews.freebsd.org/D57629
Reviewed by: imp
MFC after: 2 weeks
netlink: Indicate that ifinfomsg uses IFT_* types
On Linux struct ifinfomsg uses ARPHRD_* values, while we used IFT_*
types (which derive from SNMP ifType definitions in RFC 1573).
Update the header to reflect this.
PR: 272144
Reviewed by: pouria
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57334
(cherry picked from commit 21a75a85f0e0cc328b6e9b437d783ef0c25dc52e)
bsnmpd/snmp_hostres: fix hrFSTable remoteMountPoint leak
Free the previous value before re-strdup'ing, and initialise
remoteMountPoint to NULL in fs_entry_create() so the free() is safe on
the newly-created path
Observed via a dtrace leak snapshot on 15.0-RELEASE-p4:
data leaked = 1983, count = 1683
libc.so.7`malloc+0xa8
snmp_hostres.so.6`fs_tbl_process_statfs_entry+0x276
snmp_hostres.so.6`refresh_storage_tbl+0x502
snmp_hostres.so.6`op_hrStorageTable+0x1a
libbsnmp.so.7`0x2a2b1892ba3d
libbsnmp.so.7`snmp_getbulk+0x37f
Reviewed by: sjg, ngie
Differential Revision: https://reviews.freebsd.org/D57604
