AMDGPU: Tablegenerate TargetParser feature sets
Traditionally we maintained 2 parallel feature mechanisms,
one in clang (later moved to TargetParser), with largely
mirrored subtarget features defined in the backend. Start
directly taking feature information from the backend and putting
it into TargetParser. This is still in a compromise mid-migration
state. We still have both the legacy "ArchAttr" bitfield integer,
plus a new AMDGPUFeatureBitset field stored in the table, which
isn't yet exported.
For the moment, the new bitset is only used to populate the
feature string name map, which is the big maintainability win.
This also lists an explicit subset of exported features to
avoid churn.
Co-authored-by: Claude (Claude-Opus-4.8)
AMDGPU: Export the TargetParser feature bitset
Previously this bitset was only used to populate the feature
name string map used by clang. Eventually this will replace
the current bitmask integer. AArch64 already has a similar
interface.
Co-authored-by: Claude (Claude-Opus-4.8)
ip_mroute: Don't assume that a multicast router is running
The SIOCGETSGCNT handler may be invoked in this scenario, and if no
router has initialized the lookup table, we'll have
mfct->mfchashtbl == NULL.
PR: 297148
Reported by: Robert Morris
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Consolidate the managed-dataset registries and guard every mutator
"Is this a dataset middleware manages?" was answered by five separate registries with four membership sets and three matching algorithms: `INTERNAL_PATHS` in `plugins/zfs/utils.py`, `INTERNAL_DATASETS` in `plugins/pool_/dataset_query_utils.py`, `internal_datasets_filters` in `plugins/pool_/dataset.py`, inline literals in `alert/source/datasets.py`, and `INVALID_DATASETS` in `plugins/zettarepl.py`. None had unit coverage, and they had drifted: `<pool>/ix-applications` was creatable and then permanently invisible because one carried a trailing slash the others lacked, `<pool>/ix-apps-data` was hidden forever on a substring match, and the replication registry did not know about the apps datasets at all. A sixth spelling in `docker/fs_manage.py` tested `startswith("boot-pool/")`, so it missed `freenas-boot` entirely and reported the boot pool's own root dataset as the mounted apps dataset on any system upgraded from a FreeNAS-era install.
"May this caller change it?" was answered by a `bypass` field on seven public snapshot request models. It was declared `SkipJsonSchema`, which hides a field from the generated docs and JSON schema but does not block it at validation, so any caller holding `SNAPSHOT_WRITE` could send `bypass: true` and defeat every guard. The read side had the same defect twice: `exclude_internal_paths` on `ZFSResourceQuery`, and `exclude_internal_datasets` read out of `pool.dataset.query`'s free-form `extra` dict, where the model's `extra="forbid"` never reaches because it governs unknown model fields rather than keys inside a dict value. Either one let a caller holding nothing but read access enumerate every managed dataset, boot pool included. The root cause is the same in all three: an authorization decision encoded as request data -- a property of the caller modelled as a field of the request.
Separately, ten public mutators had no protection at all and none of them funnelled through a guarded implementation: `pool.dataset.promote`, `rename`, `set_quota`, `get_quota`, `lock`, `change_key` and `inherit_parent_encryption_properties`, both `zfs.tier` mutators, and `pool.snapshot.rename`. `promote` was the worst of them, since managed children are frequently clones and promoting one reparents its origin snapshot. `pool.snapshot.rename` turned out to be unreachable in any case: it passed a snapshot id to `zfs.resource.rename`, which rejects any name containing `@`, so the endpoint could not succeed for any valid input and had no test coverage.
- **One registry, one predicate per question.** `utils/zfs/managed_datasets.py` replaces all five, with one function per caller decision -- `hidden_from_zfs_listing`, `hidden_from_dataset_listing`, `blocked_from_mutation`, `reserved_from_user_creation`, `excluded_from_zfs_events`, `excluded_from_replication` -- each spelling out its own membership and its own matching rule where you can read both at once. Two rules cover everything: compare a whole path component, or look for `/<name>` anywhere. The names are declared once, and the sets and substring needles are built at import, so the predicates that run inside libzfs iteration callbacks pay nothing per call.
- **Behaviour preserved exactly.** Each predicate keeps the matching algorithm its callers used before, so no listing changes and nothing is newly hidden or exposed. The predicates therefore disagree with one another, and those disagreements are the point -- they are what the five registries were quietly doing in five places. Where they disagree about a single name it is visible in the source: the `ix-applications` needle for creation and events carries a trailing slash the listing needles lack, which is exactly why that dataset is creatable and then invisible. Preserved rather than corrected, because dropping the slash would newly refuse a name that is accepted today. Converging the rules would flip several unrelated consumers and is deliberately left as a follow-up. `.truenas_containers` takes part in the product listing only, reproducing today's behaviour while containers are addressed separately; that leaves it destroyable through `zfs.resource.destroy` while `pool.dataset.delete` answers ENOENT, which is written down rather than quietly fixed.
- **Two pairs of predicates decide identically today and are still written out twice.** `blocked_from_mutation` agrees with `hidden_from_zfs_listing`, and `excluded_from_zfs_events` with `reserved_from_user_creation`. Having either delegate would need undoing before the first divergence could be recorded -- the container dataset is expected to become protected without becoming hidden -- and in the second case it would also read as though events were a creation question, which they are not.
- **The overrides are off the wire.** `bypass`, `exclude_internal_paths` and `exclude_internal_datasets` are gone from the public surface, replaced by parameters on `@private` implementations, which JSON-RPC cannot populate because it dispatches through the request model. `pool.dataset.query` had no private chokepoint to move its flag onto, so `query_impl` is added and the shared body factored out behind it; a key a caller leaves in `extra` is popped and discarded rather than rejected, since it was never on a model and ignoring it fails in the safe direction. The mutation privilege is now a typed `InternalAccess` enum rather than a bool, so a stray value fails closed instead of silently permitting, and `InternalAccess.ALLOW` is a unique token that greps out the complete list of privileged callers. It is str-valued and coerced rather than identity-compared so it survives the JSON hop in `failover.call_remote`, which the audit dataset relies on. `v26_0_0` is left alone: the version adapter already drops fields absent from the newer model, and editing a frozen version would turn a silent drop into a hard failure for old clients.
- **This adds owner opt-ins, it does not merely rename them.** Sixteen call sites already passed `bypass=True`, but there are thirty-nine `InternalAccess.ALLOW` sites now, because guarding `pool.dataset.update_impl` and `zfs.resource.unload_key` pulled in owners that previously needed no opt-in at all. The new ones sit on pool import, the system dataset, audit (including the HA `call_remote` hop), docker's mount management and the container migration -- boot and failover paths, which is the argument for the guards living where they do: a missing opt-in fails loudly inside that owner's own workflow rather than silently widening access.
- **Guards live at the chokepoint.** Protection sits inside the `@private` implementations, which every mutation passes through, rather than in each public method -- a missing guard at a public boundary fails open and silently, while a missing owner opt-in fails closed and loudly. The four operations that have no chokepoint (quota, the two encryption operations, and tiering, which talks to an out-of-process daemon) are guarded at their public boundary instead, each as the first statement so the refusal precedes any lookup or feature check.
- **Gaps closed.** All ten unguarded mutators now refuse managed datasets, `pool.dataset.rename` also refuses a managed *destination* so a dataset can no longer be created at a protected name by renaming into it, `pool.dataset.delete` reports `EACCES` "is a protected path" instead of an errno-less "is an invalid location", and `pool.dataset.update` is protected explicitly rather than incidentally by the listing filter hiding its target and returning a misleading `ENOENT`. `pool.snapshot.rename` is routed at the snapshot rename endpoint and works. Docker's apps-mountpoint check asks the registry, so it recognises both boot pool names. `mount` and `unmount` are deliberately left unguarded, with the reason recorded: they toggle visibility rather than changing content, and docker legitimately mounts the apps dataset. `replication.create_dataset` is likewise left unguarded, since replication is how users back up and restore the apps dataset and the target may be a remote system whose managed paths this one cannot reason about.
- **Coverage.** A truth table pins all six predicates against thirty-four paths, including the nested and prefix look-alikes the old registries disagreed on, the whole-component split on a name carrying a snapshot suffix, and one documented divergence on an input ZFS cannot produce. A scanner test blocks a sixth registry by matching dataset-name string literals -- including inside f-strings -- outside the registry module, and was checked to catch all five of the registries it replaces; it takes the names it scans for from the registry itself, so a sixth managed dataset cannot leave it quietly looking for five, and its allowlist doubles as the convergence backlog. Integration tests cover every guarded mutator against three managed datasets, with controls proving the guards reject nothing else; the matrix fires at absent paths one level below each managed dataset, so a guard that regressed fails the test instead of destroying the boot environments.
[LoopUnroll] Fix freq accuracy calculations
This problem was reported at
<https://github.com/llvm/llvm-project/pull/182405#issuecomment-5165268733>
for the case of very large loop probabilities.
The biggest issue is that, when using linear and quadratic equations
to determine loop latch probabilities, asserts introduced by PR#182405
to verify the accuracy of the resulting loop body frequency can fail.
Another issue is that iterations introduced by PR#182404 and PR#182405
terminate upon achieving a desired accuracy, but they can iterate
longer than necessary, wasting time achieving higher accuracy than
desired.
This patch fixes the accuracy calculations to use relative differences
instead of absolute differences. It updates existing tests that
reveal the impact on the N>2 uniform case. Its adds new tests to
cover the N=1, N=2, and N>2 fast cases.
[libc] separate out TLSFTable to its own header and add unit tests
Address code review comments:
- Extract TLSFTable abstraction into tlsf_table.h to encapsulate occupancy bitmaps and bin sizing formulas without changing core allocator algorithm logic or O(1) fast paths.
- Add exhaustive unit tests in tlsf_table_test.cpp.
- Remove redundant {} default member initializers from structured list classes.
- Format heap-related files with clang-format.
TAG=agy
CONV=e64ff65b-c845-4136-9173-da6f615197ee
sys/ofed: don't stop removing stale RoCE GIDs at the first hole
When cleaning up stale GIDs the scan stopped as soon as
rdma_get_gid_attr() failed. But that can also happen for empty entries
in the middle of the table, so a single gap left everything after it
behind and the GID entries could eventually run out.
Now the whole table is scanned and the empty slots are simply skipped.
Reviewed by: kib, jhb
Sponsored by: Nvidia networking
Fixes: 6a75471dbcf0 ("OFED: Various changes from Linux 4.19")
Differential revision: https://reviews.freebsd.org/D58510
sys/ofed: fix GID table reference leak in roce_gid_update_addr_callback()
The "add missing GIDs" loop uses rdma_find_gid_by_port() to test whether
a GID already exists, but forgets to drop the reference it returns. So
every rescan that finds an existing GID leaks one, which pins the entry
and prevents its slot from ever being freed on delete.
Just release the reference once the GID is found, like the "remove stale
GIDs" loop already does.
Reported by: Wafa Hamzah <wafah at nvidia.com>
Reviewed by: kib, jhb
Sponsored by: Nvidia networking
Fixes: 6a75471dbcf0 ("OFED: Various changes from Linux 4.19")
Differential revision: https://reviews.freebsd.org/D58511
[SLP]Support copyable fmuls in fmuladd, modeled as fmuladd(a, b, -0.0)
A copyable lane holding a single-use fmul a, b is modeled as
fmuladd(a, b, -0.0), which equals fmul a, b (the add of -0.0 is exact
and preserves signed zeros), so the multiply dies instead of being
computed and gathered. Applied only when every copyable lane is such
an fmul; multi-use fmuls and mixed copyables keep the
addend/multiplicand modeling. On a tie between fmuladd and fmul main
ops, fmuladd is preferred only when the fmuls are absorbed profitably:
single-use, operands not part of the list and vectorizable as
multiplicand operands.
Original Pull Request: https://github.com/llvm/llvm-project/pull/213369
Recommit after the fix for the revert in 9e8e0d454a4c6d9aafc36c566fe831947facee0c
Reviewers:
Pull Request: https://github.com/llvm/llvm-project/pull/213757
[lldb] Identify a WebAssembly module by its build id (#213554)
A Wasm module carries the identifier its linker gave it in a `build_id`
custom section, whose payload is the length of the identifier followed
by its bytes. That identifier is the only thing that tells one build of
a module from another.
`wasm-ld` emits the section only when asked, so the API test build asks
for it. A module linked without one still has no UUID.
pkgconf: update to 3.0.5.
Changes from 3.0.4 to 3.0.5:
----------------------------
* Correctness fixes:
- Shell quoting and backslash escapes in pc(5) properties are now consumed
once, after variable substitution, instead of while splitting the property
beforehand. Quoting arriving from a variable is therefore treated like
quoting written inline, --variable reports a value as the .pc file spells
it, and fragments are escaped exactly once when rendered. This supersedes
the 3.0.4 fix, which unescaped whitespace at parse time and so hid the
escaping from consumers such as cmake's FindPkgConfig.
See https://github.com/pkgconf/pkgconf/issues/575 and
https://github.com/pkgconf/pkgconf/issues/579.
- Metadata queries no longer consult Conflicts rules between the modules named
on the command line, as reporting metadata does not combine them into a
build. This covers --license, --license-file, --modversion, --path,
--print-provides, --print-requires, --print-requires-private,
[41 lines not shown]
[SandboxVec] Rename BottomUpVec to BundleVec (#213197)
Use `bundle-vec(bottom-up)` or `bundle-vec(top-down)` to run the
bottom-up or top-down bundle vectorizer, respectively. For example:
```
opt -passes=sandbox-vectorizer \
-sbvec-collect-seeds=loads \
-sbvec-passes="seed-collection<tr-save,bundle-vec(top-down),tr-accept>" \
input.ll -S -o out.ll
opt -passes=sandbox-vectorizer \
-sbvec-collect-seeds=stores \
-sbvec-passes="seed-collection<tr-save,bundle-vec(bottom-up),tr-accept>" \
input.ll -S -o out.ll
```
This commit is NFC, except the BundleVec requiring the user to specify
the direction upon invocation.
[CIR] Attach FenvAttr when strictfp mode is in effect (#213368)
This change adds tracking of floating-point constraints via the
CIRGenFPOptionsRAII object, deriving the state from the FP features in
effect tracking in the Clang AST. When we are about to generate an
operation that may require floating point constraints, a
CIRGenFPOptionsRAII object is used to get the effective floating-point
state from the expression for which we are generating the operations.
This object in turn sets the floating-point state of the CIRGenBuilder
which uses these settings to determine whether a cir::FenvAttr should be
attached to generated objects and, if so, what its state should be.
This does not cover complex operations, AArch64 builtins, or global
constructors. Those will be updated in follow-up changes.
Assisted-by: Cursor / various models
x11-fonts/nerd-fonts: Update to 3.5.0
Upstream renamed the D2Coding font to D2Koding due to license reasons.
Consequently, the x11-fonts/nerd-fonts-d2coding subport has moved to
x11-fonts/nerd-fonts-d2koding accompanied by an entry in the MOVED file.
Added subports:
- x11-fonts/nerd-fonts-annotationmono
- x11-fonts/nerd-fonts-googlesanscode
Changed licenses:
- x11-fonts/nerd-fonts-agave (MIT -> OFL11)
- x11-fonts/nerd-fonts-arimo (APACHE20 -> OFL11)
- x11-fonts/nerd-fonts-cousine (APACHE20 -> OFL11)
Changelog:
https://github.com/ryanoasis/nerd-fonts/releases/tag/v3.5.0
PR: 297246
[2 lines not shown]
[OpenMP] Remove Wasm limitation from openmp/runtime/cmake/config-ix.cmake (#213742)
This was originally added #71297, but this limitation no longer applies
to emscripten, and wasi-sdk will surly support this once threading is
ready there.
