pkg_repo: Fix incompatible pointer
Fix incompatible variable pointer which causes compile to fail in Linux
systems.
Fix variable clevel_buf that was 'char **'' which is corrected type to 'char *'
Consolidate the managed-dataset registries and guard every mutator
## Problem
"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 entry 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.
"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. `exclude_internal_paths` on `ZFSResourceQuery` was the same defect on the read side: any caller holding `ZFS_RESOURCE_READ` could enumerate every managed dataset, boot pool included. The root cause in both cases is that an authorization decision was encoded as request data -- a property of the caller modelled as a field of the request, on a model shared between the public method and the private one.
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.
## Solution
- **One registry, with shape as a first-class concept.** `utils/zfs/managed_datasets.py` holds the entries, and separates four things that are each edited in exactly one place: an *entry* (one table row), a *view* (a decision a caller makes), a *shape* (a matching strategy, bound per view in `VIEW_SHAPES`), and *drift* (per-cell overrides, quarantined and designed to be deleted). Retargeting a view onto a different shape is a one-line edit with no call-site changes, which is what makes the eventual convergence cheap.
- **Behaviour preserved exactly.** Each view keeps the matching algorithm its callers used before, so no listing changes and nothing is newly hidden or exposed. Converging the shapes would flip several unrelated consumers and is deliberately left as a follow-up; `SHAPE_OVERRIDES` holds the two cells that would have to go first. `.truenas_containers` keeps a row bound to the product listing only, reproducing today's behaviour while containers are addressed separately.
- **The override is off the wire.** `bypass` and `exclude_internal_paths` are gone from the public models and replaced by parameters on the `@private` implementations, which JSON-RPC cannot populate because it dispatches through the request model. The 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. The fifteen owner call sites already passed `bypass=True`, so this is a rename rather than new burden. `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.
- **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 in that owner's own workflow. 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. `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 views across every shape edge, including the nested and prefix look-alikes the old registries disagreed on 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; its allowlist doubles as the convergence backlog and already records one hand-rolled membership test the audit had missed. Integration tests cover every guarded mutator against three managed datasets, with controls proving the guards reject nothing else.
security/vuxml: Fix giflib entry
The update to 6.1.3 already contains in files/ a patch for CVE-2026-26740 so use
lt instead of le to fix the version range.
PR: 296876
[flang] - Call _FortranAAssignSimple instead of _FortranAAssign for intrinsic-type array assignments.
This patch adds support for calling _FortranAAssignSimple, a faster-path for array assignments.
`_FortranAAssignSimple` is called when ALL the following conditions are true:
1. Intrinsic element type (not derived type)
2. Matching ranks (no scalar-to-array broadcasting)
3. Non-volatile
4. Not polymorphic
5. Not explicit-length character
6. Not temporary LHS
Otherwise, uses `_FortranAAssign` (or specialized variants like `_FortranAAssignPolymorphic`, `_FortranAAssignExplicitLengthCharacter`).
This is a (perhaps final) part of the fix for https://github.com/llvm/llvm-project/issues/203915
[analyzer] Fix fragile logic in VisitCXXNewExpr (#213678)
This part of the engine code had assumed that an `evalBind` call always
produced exactly one transition. This was probably always satisfied by
the existing `eval::Bind` checkers (because the code is old and I don't
know about any bugs caused by this), but it was still fragile and
problematic to rely on this undocumented property of checkers.
This commit introduces a `for` loop to ensure that all nodes produced by
`evalBind` are handled in an identical manner (the same way as the
single node was handled previously).
(Note that not passing a `State` to `makeNodeWithBinding` is equivalent
to passing the state of the predecessor node.)
We noticed this problem during the review of the NFC commit
53ee7b167d8aee0a75c1332ca4a6aa037e0869a0 and decided to put this
(arguably non-NFC) change into a separate PR.
pf: attempt to handle overlapping group and interface names
pf assumes that network groups and network interfaces share a namespace
(that is, a name is unused, a group or an interface, never both a the
same time). Unfortunately this assumption was broken when interface
renaming was introduced.
Attempt to cope with this rather than panicking. Note that this is a
band-aid, not a full solution. The correct fix is for the network stack
to go back to enforcing a single namespace for groups and interfaces.
PR: 297220
Reported by: Robert Morris
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
pf: fix securelevel off-by-one
cmd_securelevel is the securelevel at which the call should be denied.
pf (write) calls should be denied at level 3 or up (not at 2 or up as it
was), so increment these all by one.
PR: 296838
MFC after: 4 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D58377
Reland "[AMDGPU] Fix llvm.amdgcn.ballot with return width != wavefront size" (#213635)
Reverts https://github.com/llvm/llvm-project/pull/212628
This relands #211493, which was reverted because
ockl_dm_alloc/ockl_dm_dealloc in device-libs emit an i32 ballot on
wave64, which GlobalISel cannot select (one bit per lane doesn't fit).
[#212813](https://github.com/llvm/llvm-project/pull/212813) widens the
clang ballot builtins to the wavefront size so a narrower-than-wave
ballot is no longer emitted, fixing the root cause.
PR/60522: evbppc/RB800 hits MI pmap KASSERT failure
Revert the pmap_protect part of
Fix two EXECness issues
- when creating a WX mapping via pmap_enter mark the page as EXEC
- when pmap_protect adds X then ensure that pmap_page_syncicache is called
for the page.
It seems that pmap_pte_protect is designed to remove a protection and not
add it.
For the module loading the text is indeed mapped eXecute initially, and
cache maintenance is currently handled by kobj_machdep and not the pmap.
[LAA] Properly report strided access preventing store-to-load forwarding (#208791)
Original test by @fhahn in https://github.com/llvm/llvm-project/pull/191867, further reduced here.
Before this change LAA results in
> maximum safe store-load forward width of 32|0 bits
for `i32` accesses, effectively meaning that only `VF == 1` is safe, yet
not explicitly returning `false` from `couldPreventStoreLoadForward`.
This PR fixes that.
netinet6: Fix some issues with passing v4-mapped groups to IPv6 sockets.
1. EFAULT was happening because sooptcopyin() from inp_join_group() was
seeing the user-space thread descriptor in the faked-up sockopt. So, do
not attempt a user copyin(); defer to C99 initialization nulling sopt_td
for us to force a KVA memcpy().
2. It seems necessary to byte-swap ipv6mr_multiaddr.s6_addr32[3] on amd64
for similar reasons as to how the user-space initialization needed for
passing an IPv4-mapped group address also requires byte-swapping of the
0x0000FFFF field for s6_addr32[2]; it is a direct assignment to a integer
member of a struct, NOT a memcpy().
3. The assignment to imr_interface within in6_v6_mreq_to_v4() was obfuscated
by a cast back to its own type due to use of the IA_SIN() macro. Elided.
With this change, the feature gap seems to be closed; tested with a simple
link-scope IPv4 group under 224.0.0.0/24 with an mlx5(4) SR-IOV VF in bhyve.
[2 lines not shown]
mtest: Add support for exercising IPv4-mapped groups on IPv6 sockets.
This is in lieu of a full Kyua/ATF regression test, as this is an optional
feature that was beyond the scope of IETF's normative references for IPv6
multicast; support has been strictly on a best-effort basis.
Two new commands are added to mtest(8):
u mcast-addr ifname - join IPv4-mapped group on IPv6 socket
v mcast-addr ifname - leave IPv4-mapped group on IPv6 socket
Add an internal helper function __in6_v4_to_v4mapped() to perform the
converse of the IN6_IS_ADDR_V4MAPPED() check to support this use case.
Whilst __in6_v4_to_v4mapped() returns its first argument as a convenience,
avoid the temptation to dereference a pointer to that which we already hold.
Strictly the use of sockunion_t within mtest(8) more generally is a form
of controlled type punning (aliasing). Use a temporary as we overwrite
contents of su; the resultant write would overlap memory locations.
[2 lines not shown]
[libc++] Fold deque iterator benchmarks into algorithm benchmarks (#212279)
The deque::iterator benchmarks were not truly about deque::iterator, but
about specialized algorithm implementations we have for segmented
iterators. This patch handles them as such, like we do for other
specialized algorithms like vector<bool>.
www/angie-module-lua: Unbreak build after update
The module was updated but files/patch-lua-config still pointed
to the old working directory.
PR: 297198
Reported by: Sebastian Oswald <sko at rostwald.de> (maintainer)
Approved by: osa, vvd (Mentors, implicit)
MFH: 2026Q3
(cherry picked from commit 565dc2c4047d886d51024ec852352e26a7bb7c5a)
[flang] - Call _FortranAAssignSimple instead of _FortranAAssign for intrinsic-type array assignments.
This patch adds support for calling _FortranAAssignSimple, a faster-path for array assignments.
`_FortranAAssignSimple` is called when ALL the following conditions are true:
1. Intrinsic element type (not derived type)
2. Matching ranks (no scalar-to-array broadcasting)
3. Non-volatile
4. Not polymorphic
5. Not explicit-length character
6. Not temporary LHS
Otherwise, uses `_FortranAAssign` (or specialized variants like `_FortranAAssignPolymorphic`, `_FortranAAssignExplicitLengthCharacter`).
This is a (perhaps final) part of the fix for https://github.com/llvm/llvm-project/issues/203915
[flang-rt] - Lightweight runtime assignment function (AssignSimple) for intrinsic-type assignments.
This PR introduces a lightweight assignment runtime path (`_FortranAAssignSimple`) for intrinsic-type arrays
with the goal of reducing compile-time overhead seen primarily in the form of severly increased time taken by LTO.
This PR includes only the changes to the runtime (flang-rt) and as such just with this PR compile-time improvements
will not be visible.
**Problem**
When compiling Fortran code with OpenMP GPU offload and `firstprivate(allocatable_array)`, LLVM's Attributor creates excessive abstract attributes analyzing complex runtime assignment machinery:
**Symptom:**
- **Test case:** 8-element allocatable integer array with `firstprivate` clause
- **Compile time:** 24.97s (vs 0.78s for `private` - **32x slower**)
- **Root cause:** LLVM Attributor analyzing complex Fortran runtime functions
**Why this happens:**
1. `firstprivate` requires copying arrays from host to device
[43 lines not shown]
www/angie-module-jwt: update 3.4.4 => 3.4.5
Trigger CI on test files and workflow changes
Commit log:
https://github.com/max-lt/nginx-jwt-module/compare/v3.4.4...v3.4.5
PR: 297199
Reported by: Sebastian Oswald <sko at rostwald.de> (maintainer)
Approved by: osa, vvd (Mentors, implicit)
MFH: 2026Q3
