powerpc: powerpc_ipi_handler(): Stop first, preempt last
Preemption should happen last so that other IPIs have a chance to be
executed in due course, in particular hardclockintr(). So, move
handling of IPI_PREEMPT at the end.
An IPI_STOP/IPI_STOP_HARD request should be processed immediately to
avoid risks that further processing changes the system state on panic,
or worse itself causes another panic on corrupted kernel state.
While here, move IPI_AST handling just before IPI_PREEMPT. We currently
do not need to do anything for it, but if we were to, it is likely that
would have to happen after other IPIs but IPI_PREEMPT.
Reviewed by: jhibbits
Fixes: 9d5a22b928c2 ("MFp4: SMP support")
Fixes: 12640815f815 ("MFp4: SMP support")
Fixes: 7ed09a6778d3 ("powerpc: Rework IPI message processing")
MFC after: 1 week
[4 lines not shown]
x86: ipi_bitmap_handler(): Preempt last, reduce critical section
Preemption should happen last so that other IPIs have a chance to be
executed in due course, in particular hardclockintr(). So, move
handling of IPI_PREEMPT at the end.
Reduce the critical section to be in force only around hardclockintr(),
which needs it to execute entirely without preemption (because of code
it calls that can enter a critical section; interrupts are already
disabled in this handler, as usual).
The critical_exit() following hardclockintr() may cause preemption if
due. If that happens, there is no need to preempt again on IPI_PREEMPT,
so make sure sched_preempt() is not called in this case.
This fixes inadvertent removal of the optimization that sched_preempt()
should be called outside of a critical section to perform an immediate
context switch in the case of IPI_HARDCLOCK and IPI_PREEMPT being
handled at the same time.
[12 lines not shown]
x86: ipi_bitmap_handler(): Account for IPIs correctly on COUNT_IPIS
A preemption could occur before the updates to the initial CPU's IPI
counters, leading to a potential non-atomic updates of these counters
from another CPU.
Reviewed by: kib
Fixes: ff326a187907 ("x86: Restore the critical section (...)")
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60862
(cherry picked from commit 3a0e2ca3eecd3176fa7dd139e59913a67c858ac9)
sched_ule: Use TDQ_CPU() macro instead of fiddling with DPCPU
No functional change (intended).
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 79ca9f787ca92018a1374242bb77252af6fce0d0)
sched: INVARIANTS: Check sched_preempt() is called on 'curthread'
sched_preempt() does not support operating on a remote thread. If you
are looking to influence CPU allocation on another thread, see, e.g.,
cpuset_setthread(), which in the end calls sched_affinity().
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
(cherry picked from commit f19009020a33d07d7cad9393b4bf0a36f267cd07)
sched_ule: sched_affinity(): Delineate steps
No functional change (intended).
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
(cherry picked from commit a1fe7f00bc452653426493c511d288e5a4e7862d)
sched_ule: tdq_runq_add(): Scope variables, delineate the different steps
For better readability.
No functional change (intended).
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
(cherry picked from commit d5e9c642307c13b8058609f421b63e2c72bab45f)
sched_ule: tdq_notify(): Fix a typo in a comment
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
(cherry picked from commit ea1da6a51a5aa0c949fc125aece6b88a68e67a3a)
systm.h: Remove unused <sys/kpilite.h>
It only contains sched_pin_lite() and sched_unpin_lite(), which have
been unused in-tree for the past 8 years, and were only briefly used
between 6573d7580b85 ("epoch(9): allow preemptible epochs to compose")
and a760c50c9ea7 ("With epoch not inlined, there is no point in using
_lite KPI. (...)").
Additionally, these functions are redundant with the existing
sched_pin() and sched_unpin() in <sys/sched.h>, which are already
themselves inline functions. The only difference is that the
sched_*_lite() ones do not require the full definition of 'struct
thread', which may have been useful to circumvent namespace pollution.
That problem, if it materializes again, could be quickly circumvented
without this trickery by the use of non-inline functions, or using
inline functions referencing a variable filled at kernel startup with
the desired offset. The trickery of using offsets computed at
compile-time appears necessary only in the case of extremely performance
[9 lines not shown]
sched.h: Include <sys/pcpu.h> unconditionally
Even if SCHED_STATS is not defined, this header is necessary to provide
a definition of 'curthread' used in sched_pin() and sched_unpin().
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
(cherry picked from commit b6d10a962448bf03400dd381b2083d1f547f869c)
sched.h: Fix a typo and remove an extra line
Fixes: 42490d5cd29d ("sched: New scheduler interface definition scheme")
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 0bccbb9e98930f55bff5a943c881e460d4f31aec)
sched: New scheduler interface definition scheme
Define the scheduler interface once and for all (in 'sys/sys/sched.h')
and remove all code duplication related to it (function signatures, slot
names, dispatch, scheduler instance declaration), making it easier to
modify the interface or to add new schedulers.
This is implemented by defining the interface as X macros, which are
passed a macro (and additional arguments for it) that is "called" with
a variable number of arguments describing a single function of the
interface. The convention used for a function's parameters is that each
parameter is represented with two macro arguments, the first one being
the type and the second one being the name. Helper macros allow to
process arguments described in this convention in order to generate
a list of arguments for function definitions (currently, up to
4 function parameters). The chosen convention eliminates the need for
any specific declaration of functions depending on their number of
arguments.
[50 lines not shown]
cred: freebsd14_setgroups(): Remove a now-unnecessary local variable
MFC with: e6fbef451dd4 ("cred: Fix a race in the FreeBSD-14-compatible setgroups(2)")
Sponsored by: The FreeBSD Foundation
(cherry picked from commit e40d60838c9a0ebe5e5fb0e3cb00e7b08dd8c959)
cred: Fix a race in the FreeBSD-14-compatible setgroups(2)
The freebsd14_setgroups() function would try to modify the effective GID
on the current process' credentials without holding the process lock,
allowing races with other threads concurrently modifying the process
credentials. In the worst case, freebsd14_setgroups() could be
manipulating a 'struct ucred' already freed by another thread (in the
very small window after reading 'p_ucred' without lock but before
modifying the effective GID). Concurrent uses of freebsd14_setgroups()
or setcred() could also lead to non-atomic credentials modifications.
Fix this by making kern_setgroups() take a new boolean indicating
whether the passed array includes the effective GID in its first slot.
When this boolean is true, it internally keeps the effective GID in
a separate variable, pretends that the groups[] array that was passed
actually starts at 'groups + 1', do the usual steps to set the
supplementary groups and new extra ones to set the effective GID along,
without releasing the process lock in between.
[7 lines not shown]
[ARM] Fix A32 single-register PUSH/POP preferred disassembly aliases
For A32, `POP` of a single register encodes as an LDR. When the code
for this was first committed in 2011 in change 8ba76c6d5, the Arm ARM
only mentioned that `POP` is listed as the "standard syntax".
Later, in 2014, the Arm ARM DDI0487A.e, §F7.1.137 was updated to
specifically say that `POP` "is always the preferred disassembly."
Update the code and tests to reflect the Arm ARM.
sysutils/py-zfsstat: Add OpenZFS python tools
For OpenZFS Mastery book.
Anyone that has more stake in this, please take
ownership.
See https://io.mwl.io/@mwl/117555657357834894
Requested by: Michael W. Lucas <@mwl at io.mwl.io>
[analyzer] Improve node creation hygiene in MPIChecker (#238423)
Properly handle the case when node creation fails, remove a pointless
transition and some pointless state lookups.
Fixes #64647
misc/codex: Update to 0.166.0
v8 crate is now obtained from a GitHub repository instead of
crates.io. It has git submodules which have to be retrieved
separately from GitHub and Googlesource. A mechanism to secure
reproducibility of those submodules has been added to Makefile.
Changelog: https://github.com/openai/codex/releases/tag/rust-v0.166.0
Reported by: GitHub (watch releases)
[analyzer] tryRearrange: don't "cancel out" symbol in BO_Add (#237160)
In the special case when the same symbol appeared on both sides of the
top-level operator (perhaps with some integer offsets), it was cancelled
out... EVEN WHEN THE OPERATOR WAS ADDITION!
E.g. it was rearranging `(x + 1) + (x + 2)` to `3` and `x + x` to zero.
This change skips the "cancel out symbol" step for `BO_Add`, which
ensures that e.g. `(x + 1) + (x + 2)` is rearranged to `(x + x) + 3`.
Cancelling symbols is valid for all other supported operators
(subtraction and comparisons).
This bug was introduced in 2018 by
2bbccca9f75b6bce08d77cf19abfb206d0c3bc2e, but after spending 3 months in
trunk, `tryRearrange` was disabled by default for severe unrelated
(performance) issues. After that
`aggressive-binary-operation-simplification` was just one of the many
basically unsupported analyzer options, so it's not a surprise that
[5 lines not shown]
[AArch64] Skip adding BTI before PACI[AB]SPPC in AArch64BranchTargets (#236164)
PACI[AB]SPPC also has an implicit BTI instruction, so should be skipped
in addBTI similar to PACI[AB]SP.
AArch64BranchTargetsImpl is also extended to replace the signing
instruction with PACNBI[AB]SPPC, to prevent a bti instruction moving
to the middle of the prologue.
[clang][OpenMP] Fix crash on `linear(uval)` with a reference parameter (#237754)
Fixes #108166
`linear(uval(x))` crashed when `x` is a reference parameter. For `uval`,
Sema read the initial value from the reference's initializer instead of
the reference, and a parameter has none, so a null `Expr` reached
`DefaultLvalueConversion`. Even with an initializer this was wrong: a
defaulted `int &x = g` made the loop update `g`, and in a `parallel`
region or a lambda it could name an uncaptured variable.
Drop the shortcut in `ActOnOpenMPLinearClause` and
`FinishOpenMPLinearClause`, so a `uval` item is read from and written
back through the reference, like `val`. That is what the spec says for
loop constructs, where `uval` only adds the requirement that the item be
a reference, which is still checked.
AI Assisted!
[UpdateTestChecks] Handle lit's %if in update_cc_test_checks.py (#238255)
Handle run lines containing lit `%if`s by ignoring the condition and
unwrapping, similar to other update scripts.
[AMDGPU] Infer mul24 known bits with unknown operands
Do not stop GlobalISel known-bits analysis when a mul24 operand has no known bits. Truncating to 24 bits and extending to the result width can still establish useful product bounds through the shared helper added by #236738.
Cover both operand orders, ignored high bits, zero and overflow boundaries, and i64 results without limiting known bits to the i32 operand width.
[lldb-dap] Don't collect module statistics for the statistics event (#236413)
Use the stats options to build GetStatistics to avoid computing data
that lldb-dap drops.
