[RISCV] Add SDNPCommutative to riscv_mulhr/riscv_mulhru/riscv_mulq/riscv_mulqr. NFC (#217702)
NFC because no isel patterns make use of this property today.
Merge tag 'fs_for_v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
Pull ext2, udf, isofs, and quota updates from Jan Kara:
- Remove deprecated quota code printing warnings about exceeded quota
directly to console
- Various udf & isofs hardening for handling of corrupted filesystems
- Fix a possible data loss in udf when converting files from inline to
out-of-line format
- Simplify EIO error handling in ext2 xattr code
* tag 'fs_for_v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
udf: Fix data loss when converting inline inodes to out of line
udf: Move udf_map_block() up
ext2: Simplify error handling of IO error when adding xattr
isofs: Drop support of directory entries straddling blocks
[12 lines not shown]
Merge tag 'fsnotify_for_v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
Pull fsnotify updates from Jan Kara:
"A couple of assorted fixes (mostly stuff spotted by Sashiko) for
fsnotify subsystem.
I'm also removing Matt as a reviewer because he was not active in
fsnotify in last years and after he stopped working for Google I don't
have a working contact to him"
* tag 'fsnotify_for_v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
fsnotify: Fix stale object mask after concurrent mark updates
fanotify: report full event length for FIONREAD
fanotify: fix use-after-free of file range info
fanotify: stop permission watchdog when timeout is zero
fsnotify: Remove Matt Bobrowski as a reviewer
fanotify: initialize permission event watchdog state
Drive the alert enforcement sites from unit tests
This commit adds changes to test the four sites in plugins/alert.py that consume an applicability rule, rather than only the rules themselves. The run and send axes had no execution coverage at all: emptying the excluded-source set, deleting the alert purge loop, or making the send filter answer True all left the suite green. These drive __run_alerts and send_alerts against stub sources through a shared harness, and record what the policies delete, since dropping the purge loop still leaves the alert list correct and nothing else can see it.
The purge is worth pinning on its own because it destroys state: a source whose rule stops admitting this system loses the alerts it had persisted, and when it applies again they come back with a fresh uuid and their dismissed flag cleared. There is also an asymmetry three lines apart in that loop, deliberate but unasserted until now, where a rule-excluded source is purged and a gate-blocked one is only skipped.
Also fixes both AST scanners. BondStatus is a shipped source that does not carry the AlertSource name suffix, so the black hole check never saw it or the three classes it creates; keying off the subclass relation the loader itself uses picks it up and keeps the two modules from disagreeing. Reading attribute-spelled bases stops a class written as base.AlertClass dropping out of the frozen inventory with nothing to show for it. Both scanners now carry an invariant test, so a shape they cannot model fails instead of silently shrinking what is covered.
Keep uncorrected memory error alerts on Minis
This commit fixes an issue where the uncorrected memory error alert stopped running on Minis even though they carry ECC memory and populate the same EDAC counters the source reads. TRUENAS_HARDWARE excludes MINI by construction, so a licensed Mini lost a proactive support warning it used to get, and any alert it was already sitting on was purged on upgrade without a cleared notification.
TRUENAS_OR_MINI_HARDWARE is the union of the two hardware names, composed from them rather than defined as "not GENERIC" so a hardware class added later has to be added here deliberately. MemorySizeMismatch stays on TRUENAS_HARDWARE because its own check returns early without an HA licence.
Only report a missing license on HA capable systems
This commit fixes an issue where an unlicensed R-series or Z-series started getting told to contact support about a license it was never sold. Those chassis are appliances so they satisfy the hardware rule, but they cannot fail over, and on 26 the product_type disjunct meant a system with no license only reached this alert when it was HA capable. HA capability is a chassis probe the applicability axes deliberately do not carry, so the test sits in check_sync rather than in applies_to.
Run the local account expiration alert everywhere
This commit fixes an issue where the local account expiration alert stopped running on Minis even though they can still turn on password aging: max_password_age sits behind the STIG entitlement, whose vector grants on the key column of either hardware side, and that key is injected into every legacy licence. The source is also the admin lockout recovery, since it regenerates shadow a day before the last full admin password ages out, so excluding a system that can arm password aging leaves it with no way back in short of a reboot.
check() already returns early unless max_password_age is set, so that early return is the applicability test and the rule is dropped rather than widened. On a system that cannot set the option the daily cost is one config read.
Keep the FIPS misconfiguration alert on licensed Minis and whiteboxes
This commit fixes an issue where the FIPS misconfiguration alert stopped running on licensed Minis and licensed whiteboxes even though those systems can still enable FIPS: the STIG vector is key-only on both hardware sides and STIG is injected into every legacy licence, so they are entitled while TRUENAS_HARDWARE excluded them by construction.
EXPECTED_TO_BE_LICENSED is a strict superset of both the old product_type gate and the hardware gate, so nothing loses coverage, unlicensed appliances keep the check that catches FIPS being active when it was never configured, and licensed whiteboxes that could never see this alert are now covered too.
Type alert applicability against AlertSource and AlertClass
This commit adds changes to drop the Declaration protocols in favour of TYPE_CHECKING imports of AlertSource and AlertClass, which is what review asked for, and to tighten the surface while we are in there: rule_name is no longer re-exported now that declaration_rule_name is the only entry point production goes through, and the Rule docstring keeps just the part that constrains how you write one, which is to name it so the black-hole diagnostic has something to report.
Dropping the protocols makes alert.applicability depend on alert.base, and import-linter counts TYPE_CHECKING imports, so that broke the package layering contract: engine reached vocabulary and snapshot through alert.base importing the whole package. alert/base.py now takes Rule from the engine module directly, which is the only thing it ever wanted, and the contract holds without an ignore.
Document alert applicability and the frozen inventory
This commit adds changes to document the applicability axes and the frozen inventory in the alert plugin docs, since the only record of how to regenerate that file lived in the test module's own docstring and you only found it after CI had already failed. The populations are pulled in with automodule so a new one documents itself, and the page spells out what does and does not require a regeneration plus what each guard test means when it fails.
Remove the broken SATA DOM wear alert
This commit adds changes to delete the SATA DOM wear alert source and its two classes. The source calls disk.sata_dom_lifetime_left, which was removed in 25.10 and has no implementation anywhere, so it raises on every run on any M or Z series chassis and produces nothing but alert source failures.
Alerts already persisted on existing systems clear on the next start through the stale source check in initialize, which runs before the policies are built, so nothing is announced as cleared. No migration is needed, matching how every previous alert source removal was handled.
Move alert gating onto hardware and license axes
This commit adds changes to give every declaration under alert/source its own applicability rule on the decoupled hardware and license axes, and points the enforcement sites in plugins/alert.py at those rules instead of system.product_type. The products lines stay for now because the API field still reads them. HA classes take a hardware applies_to alongside listed_when on purpose, so on iX hardware whose HA licence is absent or lapsed they leave the settings catalogue without being silenced, and a source that no longer applies now has its stored alerts dropped rather than stranding them undismissable. The two scheduled-reboot classes are the exception: they are gated on the HA licence itself, so a system without one stops seeing them at all.
sata_dom_wear is knowingly shipped in a broken state: its source calls disk.sata_dom_lifetime_left, which was removed in March 2025, so appliances will see the check fail. That is a deliberate, signed-off decision and not an oversight.
The checked-in matrix under pytest/unit/alert/golden spells out old versus new applicability per population for every declaration, and its test regenerates and diffs it so no population change lands unread.
Say which systems the enclosure alerts newly reach
This commit adds changes to test the failover run gates and to correct what the enclosure change was described as affecting. post_failover_blackout and require_stable_peer move out of the run loop into source_run_gates_pass so both can be checked without a middleware object or a running service, and a frozen inventory test pins which sources carry them and what each one is gated on.
failover_related was gating enclosure_status on an HA licence, which is a licensing predicate in front of a hardware question. Enclosure faults are now reported on every iX appliance that lacks an ENTERPRISE_HA licence, both unlicensed appliances and single controller licensed ones (ENTERPRISE_SINGLE, FREENAS-CERTIFIED). The earlier note said only "unlicensed appliances", which undercounts the fleet by the whole licensed single controller half. EnclosureHealthy is INFO and is raised once per enclosure, expansion shelves included, so affected systems will see several new informational alerts.
The matrix legend claimed a source row meant the source is ran, which was never true: it models applies_to only, and never post_failover_blackout, require_stable_peer, the schedule or source locks. That is the only change to the golden file.
Express alert applicability rules as functions and cache them once
This commit adds changes to replace the applicability rule dataclasses with plain functions that take facts, and to route every applicability answer through a single Applicability object holding one reading of those facts and memoizing per declaration. Nothing in the tree ever introspected rule structure, so the isinstance dispatch and the AnyOf/AllOf combinators go away with it, and because the seven vocabulary names are unchanged no alert declaration moves and the golden matrix is byte for byte identical.
The five separate get_facts() reads in the alert plugin become one, invalidated on system.post_license_update so an upload takes effect on both nodes at once. A None license is never cached, since get_license() returns None both for "no license" and "the daemon did not answer" and we do not want a hiccup to stick until restart.
Add an applicability engine for alerts
This commit adds changes to give alerts a way to state which systems they are meaningful on in terms of two independent axes, hardware class and license, instead of the conflated product_type predicate they lean on today. The engine is pure and delegates the HA question to the entitlement policy so there stays one definition of it in the tree.
Nothing declares the new applies_to/listed_when slots yet and no enforcement point reads them, so this is inert on its own; the declarations and the call sites follow.
Name alert applicability rules and detect black-holed alerts
This commit adds changes to give the alert applicability engine one name per population instead of thirty open-coded rule constructions, and to catch alerts that are created but can never be displayed.
The rules alert declarations gate on now live in a vocabulary module next to the engine, so TRUENAS_HARDWARE is defined once rather than built at eighteen sites in two competing conventions. LicenseRule collapses into EntitlementRule, which asks the entitlement policy about any feature rather than the two the old enum could spell, so STIG and everything after it is a one-line declaration. AllOf joins AnyOf in the algebra, listed_when becomes listed_only_when to say that it narrows, and AlertFacts is gone in favour of the identical EntitlementFacts that applies() was converting to anyway.
A source whose rule is satisfied where its class's rule is not creates alerts that are stored and never shown. Nothing checked for that, and since the failover declarations deliberately straddle the two axes it is no longer something a reviewer can spot by eye. A test now infers the source to class relation out of check() and asserts the implication across every population, with a runtime guard logging the cases static analysis cannot see. It found four pre-existing ones in memory_errors and sensors, which are fixed by narrowing the sources so nothing user visible moves.
One behaviour change worth a release note: failover_related was gating enclosure_status on an HA licence, which is a licensing predicate in front of a hardware question, so unlicensed appliances will now report enclosure faults they were previously silent about. The flag is renamed post_failover_blackout to name what it actually contributes.
Remove the product_type gate from alerts
This commit adds changes to delete `products` from every alert declaration now that the hardware and license axes carry the gating, along with the `product_types` field it fed in `alert.list_categories` and the unused `AlertService.product_type` helper. The applicability matrix loses its old-versus-new comparison and becomes a frozen inventory of what each declaration covers; the declared answers are unchanged from the previous commit, cell for cell.
The API field is removed outright rather than deprecated because nothing consumes it - it exists in no earlier API version and has no client in the WebUI, api_client or midcli, so the downgrade adapter's strip loop is already a no-op here. Forward-porting this to master will need a `to_previous` on `AlertCategoryClass`, because there v26_0_0 is frozen with the field required and the version adapter only backfills fields that are not required.
[NFC] Mark truncated-profile.test unsupported on zos, similar to existing tests that use printf (#217742)
follow up to #211281
Co-authored-by: Wael Yehia <wyehia at ca.ibm.com>
[DWARF] Fix DW_OP_LLVM_user sub-operation name lookup. (#217480)
LlvmUserOperationEncodingString returns a name with a "DW_OP_LLVM_"
prefix, but getLlvmUserOperationEncoding matched the suffix (subop)
name. This patch updates the latter to match the full name.
Assisted-by: LLM
Merge tag 'nfsd-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux
Pull nfsd updates from Chuck Lever:
- CB_NOTIFY support for NFSD's NFSv4.1 directory delegations
The server used to recall a delegation as soon as the directory
changed. NFSD now watches delegated directories through fsnotify and
reports adds, removes, renames, and directory attribute changes,
carrying the filehandle and attributes of the affected entry, so
clients can keep their caches. Some of the NOTIFY4 flags come from
RFC 8881bis (Jeff Layton)
- Continued netlink work
A new server-stats-get operation reports what /proc/net/rpc/nfsd
publishes, plus NFSv4 callback counts, and SUNRPC now keeps its
per-procedure call counts per network namespace, so a container sees
its own numbers. nfsstat reads all of this over netlink, with a
[43 lines not shown]
[NVPTX] Honor !atomic.ignore.denormal.mode on atomicrmw fadd
PTX atom.add has a fixed denormal behavior that the program cannot
control: atom.add.f32 flushes denormals on global memory but not on
shared, and atom.add.f16 never flushes. When that disagrees with the
function's denormal mode, the backend expands the atomic into a CAS loop
so the denormal behavior is preserved.
!atomic.ignore.denormal.mode says the denormal behavior of this
particular atomic does not matter, so use the native instruction even
when it disagrees. This is the same thing -nvptx-allow-ftz-atomics does,
except per-instruction instead of per-compilation, which lets a frontend
opt in only the operations it knows about -- notably CUDA's atomicAdd(),
which is defined in terms of atom.add.
Note that -nvptx-allow-ftz-atomics defaults to true, so the new behavior
is only observable with -nvptx-allow-ftz-atomics=false.
Co-authored-by: Artem Belevich <tra at google.com>
[clang][NVPTX] Emit !atomic.ignore.denormal.mode for CUDA atomics
CUDA's atomicAdd() family is defined in terms of PTX atom.add, whose
denormal behavior is fixed by the hardware. Without any annotation the
backend has to assume the function's denormal mode must be honored and
expands these into CAS loops whenever the two disagree. Mark them with
!atomic.ignore.denormal.mode so the native instruction is used.
That covers the __nvvm_atom_*_add_gen_f builtins that atomicAdd(),
atomicAdd_block() and atomicAdd_system() are written in terms of, plus
C11/C++11 atomics under -fatomic-ignore-denormal-mode and the
[[clang::atomic(ignore_denormal_mode)]] attribute, which requires
teaching the NVPTX target about AtomicOptions.
The condition for when the metadata is meaningful is now shared with the
AMDGPU and SPIR-V targets in addAtomicIgnoreDenormalModeMetadata(). It
takes an AllowHalf flag because whether f16 denormals are observable is
target specific: PTX exposes no FTZ control for f16 operations, so
atom.add.f16 never flushes and the opt-in is meaningful there, whereas
[3 lines not shown]
[IR] Generalize !amdgpu.ignore.denormal.mode into !atomic.ignore.denormal.mode
The !amdgpu.ignore.denormal.mode metadata tells the backend that an
atomicrmw fadd need not honor the function's denormal mode, so a native
atomic instruction whose denormal behavior is fixed in hardware may be
used instead of a CAS loop. Nothing about that is AMDGPU specific: NVPTX
has exactly the same problem with atom.add, whose FTZ behavior depends on
the address space and cannot be controlled.
Promote it to a target independent fixed metadata kind,
!atomic.ignore.denormal.mode, and switch the AMDGPU, SPIR-V and OpenMP
producers and consumers over to it. Document it in LangRef, and point
AMDGPUUsage at that description rather than duplicating it.
Existing IR keeps working: AutoUpgrade renames the metadata on atomicrmw
instructions when parsing textual IR and when materializing bitcode. The
upgrade is deliberately scoped to atomicrmw rather than being applied to
every attachment of that name, since that is the only place the metadata
was ever meaningful. Because bitcode can be materialized one function at
[6 lines not shown]
Merge tag 'for-linus-7.3-ofs1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux
Pull orangefs updates from Mike Marshall:
"Fixes:
- fix double-free of trailer_buf
- skip leading spaces before parsing client debug masks
Cleanup:
- Remove commented out code
New:
- use folio_pos() and folio_size() in orangefs_page_mkwrite()"
* tag 'for-linus-7.3-ofs1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux:
orangefs: skip leading spaces before parsing client debug masks
orangefs: Remove commented out code in find_cached_xattr
orangefs: use folio_pos() and folio_size() in orangefs_page_mkwrite()
orangefs: fix double-free of trailer_buf on readdir copy failure
