lagg: re-check port caps after bringing up a port
Some nic drivers (including iflib) do not initialize if_hwassist
until after the interface is brought up. If a lagg member is included
in a lagg when its not yet been brought up, that will cause lagg to see
if_hwassist=0 and will disable all checksum offload, etc, on the interface.
This is almost impossible to debug without kgdb or dtrace, as ifconfig does
not surface if_hwassist.
Fix this by re-calculating lagg caps (including if_hwassist) after adding a port.
I encountered this problem when I had a commented-out if_foo1=up entry in
my rc.conf that i neglected to uncomment when I was re-configuring a lagg.
Sponsored by: Netflix
Reviewed by: markj, zlei
Differential Revision: https://reviews.freebsd.org/D58062
(cherry picked from commit 1cce5ef05d7ba077b0cb29d30b59f3a862e7e5ae)
bhyve.8: add details on using TPM with UEFI
Add a note that UEFI VMs using TPM devices should be configured
to use a varfile. Some UEFI boot loaders, such as shim, update
persistent boot variables and then reset the system when a TPM is
present. Without a writable varfile, the VM may be reset repeatedly.
Add a TPM device example to the examples list.
While here, add a missing "\" to the "uefivm" example, and add ".Pp"
before the vCPU pinning examples for consistency with other examples.
PR: 287326
Reviewed by: michaelo, ziaee
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D60181
(cherry picked from commit ff2efe65a89a943beec4dd4cc956f5e075a921be)
msun: fix behaviour of nextafter*() and nexttoward*() for MAX value
For an edge case at an extreme, e.g., nextafter(-DBL_MAX,-INFINITY)
do not return x+x. Instead, evaluate x+x and assign it to a volatile
to raise an exception, and then fall through to return the correct
result in current rounding mode.
PR: 299389
MFC after: 6 days (for inclusion into releng/15.2)
libc: Fix C23 version macro visibility
In headers that existed prior to C23, these should be visible only in
C23 or BSD mode.
Fixes: 0fe73dcf7c32 ("libc: Add <assert.h> C23 feature test macro")
Fixes: 1f09e354297c ("sys/limits.h: Add BOOL_MAX, BITINT_MAXWIDTH, and C23 feature test macro")
Fixes: cd0727ec709b ("libc: Add <stdio.h> C23 feature test macro")
Fixes: fc9d02cb29ed ("libc: Add <time.h> C23 feature test macro")
Fixes: 4aeed6e9d213 ("libc: Add <setjmp.h> C23 feature test macro")
Reviewed by: fuz, kfv, dteske
Differential Revision: https://reviews.freebsd.org/D59272
(cherry picked from commit 5076e9b5463afa47cf2e7689431d3dd33e5b15cb)
libc: Restore prior C23 include guards
To avoid any sort of POLA violation, this commit restores old
guards and defines the C23 feature test macros in addition to
them. This is to close off whole class of possible breakage,
rather than patching it case by case.
Reported by: dim
Reviewed by: dim, dteske, fuz
Approved by: dim, dteske (mentor), fuz (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D58911
(cherry picked from commit 8d29d242964976d9ffa89387d97de87d6cedc886)
libc: Add <stdio.h> C23 feature test macro
Define the __STDC_VERSION_STDIO_H__ feature test macro now that
the header fully conforms to C23.
Reviewed by: fuz
Approved by: fuz (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D58842
(cherry picked from commit cd0727ec709bb54f8f82104f6113284a15dd3464)
sys/limits.h: Add BOOL_MAX, BITINT_MAXWIDTH, and C23 feature test macro
Add BOOL_MAX and BITINT_MAXWIDTH macros for C23 compliance, and
define the __STDC_VERSION_LIMITS_H__ feature test macro now that
the header fully conforms to C23.
Reviewed by: fuz
Approved by: fuz (mentor)
MFC after: 1 month
Pull Request: https://github.com/freebsd/freebsd-src/pull/2352
(cherry picked from commit 1f09e354297ce571353210c23e50ef6fc19ce382)
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.
[7 lines not shown]
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
[14 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.
[4 lines not shown]
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
[2 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>
[3 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
(cherry picked from commit 9d87c1aac4a84ac5e82acf872f645a7202977204)
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
(cherry picked from commit 28cecfe27964fdb67497800f5dcd5d3e1033727f)
