Merge tag 'smp-core-2026-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull SMP core updates from Thomas Gleixner:
- Switch smp_call_on_cpu() to user system_percpu_wq instead of
system_wq a part of the ongoing workqueue restructuring
- Improve the CSD-lock diagnostics for smp_call_function_single() to
provide better debug mechanisms on weakly ordered systems.
- Cache the current CPU number once in smp_call_function*() instead of
retrieving it over and over.
- Add missing kernel-doc comments all over the place
* tag 'smp-core-2026-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
smp: Use system_percpu_wq instead of system_wq
smp: Improve smp_call_function_single() CSD-lock diagnostics
smp: Get this_cpu once in smp_call_function
smp: Add missing kernel-doc comments
[AArch64] Check Subtarget via STI in getInstSizeInBytes (#192089)
The InstSizes test (`llvm/unittests/Target/AArch64/InstSizes.cpp`)
destroys the Subtarget field early (`ST` created on the stack in
[`createInstrInfo`](https://github.com/llvm/llvm-project/blob/40a585e742ed6b28306d7511380079325ba1a003/llvm/unittests/Target/AArch64/InstSizes.cpp#L32)),
causing a use-after-free if it is used in `getInstSizeInBytes`. This
causes a failure when running the test with hwasan (reported by build
bot). To fix this, this PR switches to using `STI` instead of
`Subtarget` in `getInstSizeInBytes` for checking `isLFI`, which survives
for the lifetime of the test.
I think fixing the test itself (the root of the issue, as far as I can
tell) would be more involved. Perhaps I should open an issue for it
though?
I have tested the fix on an AArch64 machine with hwasan to confirm that
it resolves the issue.
Merge tag 'timers-vdso-2026-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull vdso updates from Thomas Gleixner:
- Make the handling of compat functions consistent and more robust
- Rework the underlying data store so that it is dynamically allocated,
which allows the conversion of the last holdout SPARC64 to the
generic VDSO implementation
- Rework the SPARC64 VDSO to utilize the generic implementation
- Mop up the left overs of the non-generic VDSO support in the core
code
- Expand the VDSO selftest and make them more robust
- Allow time namespaces to be enabled independently of the generic VDSO
support, which was not possible before due to SPARC64 not using it
[25 lines not shown]
[lit] Add an option to lit which ratelimits progressbar output. (#186479)
Add a new option --min-output-interval, which ratelimits updates to the
progress bar.
When running Lit with the full curses progressbar, it updates both the
bar, and the status text below on every test completion. Running
check-llvm on my laptop runs about 44k tests and takes about 260 seconds
for a release build. Or about 171 tests/second on average.
Moreover, when ssh'd to another host, this generates quite a bit of
traffic. Using tcpdump, I measured the traffic for a run of check-llvm
and -clang. With all updates, its about 8.7 megabytes. With a rate limit
of 5 update/sec, this came down to 175 kilobytes. This can be
significant on slow/metered connections.
This patch adds an option to limit lit's output to once per a given
interval. This only affects the progressbar and status message below,
not any log messages above. It also does not affect anything when not
[5 lines not shown]
[Flang] [OpenMP] [MLIR] Add lowering support for OMP ALLOCATE directives and its clauses (#187167)
This patch implementation is primarily focused on
- Lowering to LLVM IR, by generating appropriate kmpc_alloc() and kmpc_alligned_alloc() calls for variable(s) and before the end of scope generating kmpc_free() for the same variable(s).
- Also handled, usage of array variables in the OMP ALLOCATE directive.
- Define omp.allocate_free operation in MLIR and slight changes to existing MLIR definition of ALLOCATOR clause.
- Add test cases for variations of usage of OMP ALLOCATE directive and its clauses ALIGN and ALLOCATOR.
[IR] treat nofpclass as a poison-generating return attribute (#192016)
- For: #191338
Failing nofpclass attribute will generate poison.
This change adds nofpclass attributes to
`hasPoisonGeneratingReturnAttributes`/`dropPoisonGeneratingReturnAttributes`.
NAS-140632 / 26.0.0-BETA.2 / Add LIO as an alternative iSCSI/FC target stack (by bmeagherix) (#18741)
Adds `ISCSIMODE.LIO` (mode=2) as a selectable iSCSI target stack
alongside the existing SCST modes. The implementation is a "big switch"
— selecting LIO and restarting the iSCSI service brings up LIO with the
same configured targets, extents, and initiator ACLs that SCST was
serving. No data disruption; initiators reconnect and see the same
device identities.
Device identity (VPD page 0x83 NAA designator) is preserved across
migration by reverse-engineering the stored TrueNAS NAA into LIO's
company_id + vpd_unit_serial components, ensuring initiators and
multipath stacks see no device identity change.
Switching from SCST to LIO is blocked with a clear error if the
configuration cannot be faithfully represented in LIO: open initiator
groups with CHAP, multiple discovery-auth credentials, multiple CHAP
credentials per auth tag, iSNS servers, or auth_networks on any target.
[17 lines not shown]
[CIR] Implement __builtin_verbose_trap (#191935)
Route BI__builtin_verbose_trap to the existing emitTrap() path so that
it no longer hits the NYI fallback. Debug info message attachment from
the string arguments is not yet implemented (tracked by
MissingFeatures::generateDebugInfo).
This is the single largest NYI category in libcxx testing, unblocking
~1,008 test failures.
CTL: add ATF tests for REPORT SUPPORTED OPCODES
This includes a regression test for CVE-2024-42416
MFC after: 2 weeks
Sponsored by: ConnectWise
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D46613
CTL: add ATF tests for REPORT SUPPORTED OPCODES
This includes a regression test for CVE-2024-42416
MFC after: 2 weeks
Sponsored by: ConnectWise
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D46613
[RISCV] Prevent emitting vsetvli with e32alt or e64alt. (#191960)
The e32alt and e64alt encodings for vtype are reserved.
Non-fp instructions ignore altfmt and we want to use that to avoid
vtype toggle when using load, store, slide, gather, etc. to manipulate
bf16 vectors. This is why we have a Demanded bit for AltFmt.
We need to make sure we don't keep the AltFmt set when we're changing
SEW to 32 or 64.
A new isValidVType function has been added to help catch illegal
vtype earlier.
