LLVM/project 1915dfalldb/source/Plugins/Process/Windows/Common NativeProcessWindows.cpp

[lldb][Windows] handle exception first to keep track of the stop reason (#206469)

`NativeProcessWindows::OnDebugException` called
`ProcessDebugger::OnDebugException` before handling the exception. That
ordering races on the first breakpoint:

1. The launch thread blocks in
`ProcessDebugger::WaitForDebuggerConnection`, waiting on
`m_initial_stop_event`.
2. A debug exception arrives and
`NativeProcessWindows::OnDebugException` is called.
3. It calls `ProcessDebugger::OnDebugException` first, which signals
`m_initial_stop_event` and wakes the launch thread.
4. Only then does `NativeProcessWindows::Handle...Exception` set the
process state and stop reason.

When the bug occurs, the launch thread wakes up (3) before the stop
reason is set (4), and the first stop can be reported with a missing or
wrong reason.

    [18 lines not shown]
DeltaFile
+13-6lldb/source/Plugins/Process/Windows/Common/NativeProcessWindows.cpp
+13-61 files

LLVM/project 6197f83clang/test/CodeGen/AArch64/neon add.c

[CIR][test] Use global instcombine RUN line in AArch64 neon add.c (#206292)

Related to https://github.com/llvm/llvm-project/issues/185382

Follow-up to https://github.com/llvm/llvm-project/pull/204989

Include `instcombine` into the global LLVM RUN line and remove the
separate `LLVM-IC` prefix that only covered the narrowing-addition tests
in `clang/test/CodeGen/AArch64/neon/add.c`.

Update LLVM CHECK to match the `instcombine` output: bitcast checks are
dropped, the inferred `nsw`/`nuw` flags are added on the widening adds,
and unused shuffle operands are canonicalized to `poison`.
DeltaFile
+298-364clang/test/CodeGen/AArch64/neon/add.c
+298-3641 files

LLVM/project f15288cllvm/lib/Transforms/Vectorize VPlanTransforms.cpp, llvm/test/Transforms/LoopVectorize/VPlan buildvector-first-lane-only.ll

[VPlan] Replace first-lane uses of BuildVector. (#206566)

Replace uses of the first lane of a BuildVector with the first operand.
DeltaFile
+5-9llvm/test/Transforms/LoopVectorize/VPlan/buildvector-first-lane-only.ll
+8-0llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp
+13-92 files

FreeBSD/ports 1d9ec9fscience Makefile, science/amrex pkg-plist Makefile

science/amrex: New port: AMReX: Software Framework for Block Structured AMR
DeltaFile
+372-0science/amrex/pkg-plist
+37-0science/amrex/Makefile
+6-0science/amrex/pkg-descr
+3-0science/amrex/distinfo
+1-0science/Makefile
+419-05 files

FreeBSD/ports 31b946dscience Makefile, science/py-phonors distinfo Makefile

science/py-phonors: New port: Rust kernels for phonopy and phono3py
DeltaFile
+175-0science/py-phonors/distinfo
+114-0science/py-phonors/Makefile
+6-0science/py-phonors/pkg-descr
+1-0science/Makefile
+296-04 files

FreeBSD/ports 64930b1misc/py-langchain-tests Makefile

misc/py-langchain-tests: Update dependency spec and test results
DeltaFile
+2-2misc/py-langchain-tests/Makefile
+2-21 files

LLVM/project 86e23d2clang/lib/CIR/CodeGen CIRGenExpr.cpp, clang/test/CIR/CodeGen enum-bool.cpp

[CIR] Load enums with a boolean underlying type (#205880)

emitLoadOfScalar reported NYI for any scalar whose type has a boolean
representation but isn't the builtin bool, so loading an enum with a fixed
bool underlying type (e.g. enum E : bool) failed to compile. The errorNYI
also left the function's entry block without a terminator, so the translation
unit then failed CIR module verification.

Such an enum converts to !cir.bool (via convertType of its underlying type),
and convertTypeForMem does not widen it, so the cir.load result is already the
literal CIR type CIR uses for that enum everywhere. CIR keeps bool in
!cir.bool through CIRGen and defers the in-memory i8 widening to LowerToLLVM
(see the emitToMemory comment), so no register/memory conversion is needed at
this point. The fix drops the errorNYI and returns the loaded value, matching
the plain-bool path directly above it.

The same guard also covered _BitInt(1), which converts to !cir.int<1> and
follows the identical deferral; it now loads too. This does not change the
in-memory representation of either type, which LowerToLLVM still owns.

    [2 lines not shown]
DeltaFile
+35-0clang/test/CIR/CodeGen/enum-bool.cpp
+5-2clang/lib/CIR/CodeGen/CIRGenExpr.cpp
+40-22 files

FreeBSD/src 9dea58fsys/security/mac_do mac_do.c, tests/sys/mac/do invalid_configs.sh

MAC/do: Fix double-free on parse error after "executable paths" feature

parse_rules() has been calling toast_rules() in case of a parse error in
order to deallocate the 'struct rule' objects it has constructed up to
that point.

toast_rules() would take a pointer to a full 'struct rules' object, and
besides freeing all 'struct rule' referenced by it, would also free the
holding 'struct rules' itself.

With the introduction of the "executable paths" feature, and the
embedding of 'struct rules' into 'struct conf', meaning that the
lifecycle for 'struct rules' was no longer independent, toast_rules()
was changed not to free the passed 'struct rules' (as it was a field of
a 'struct conf' object).  Unfortunately, this change was not completed
with a reinitialization of the rules list head, so the 'struct conf'
object would continue to reference just-freed rules, which then would be
freed a second time on destruction of that container.


    [18 lines not shown]
DeltaFile
+8-8sys/security/mac_do/mac_do.c
+14-0tests/sys/mac/do/invalid_configs.sh
+22-82 files

FreeBSD/src 531c3easys/security/mac_do mac_do.c

MAC/do: Update copyright

Update years for the Foundation.

While here, remove the initial '/*-' which has been useless for a long
time.

While here, add a missing space on bapt@'s copyright line (approved by
him).

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

(cherry picked from commit fcb0018634c77fe32ed99bca00f856af18ed240b)
DeltaFile
+3-3sys/security/mac_do/mac_do.c
+3-31 files

FreeBSD/src 29c5581sys/security/mac_do mac_do.c

MAC/do: Do not skip blanks when parsing executable paths

The kind of tolerance we apply to parsing rules, whose format we have
defined, cannot be applied to paths since blank characters are allowed
there.

There is still the limitation that no escape character is currently
supported, and so it is not possible to configure a path having a ':'
character.

Reviewed by:    bapt
Fixes:          9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

(cherry picked from commit 1fa1e3f3950fc0593ab73ea075c24c9bfbe8afd6)
DeltaFile
+1-1sys/security/mac_do/mac_do.c
+1-11 files

FreeBSD/src ac9d12fsys/security/mac_do mac_do.c

MAC/do: Serialize installing/modifying some jail's configuration

See the immediately preceding commit for explanations on what this is
fixing.

When setting 'mac.do' to 'inherit' on a jail with 'mac.do.rules' and
'mac.do.exec_paths' also specified in the same call, ensure that the
check that these passed parameters are the same as those to be inherited
is atomic with respect to enabling the inheritance (i.e., removing the
jail's 'struct conf' object).  (See previous commit "MAC/do: Fix the
recent logic to set jail parameters, make it more tolerant" as for why
this check exists.)

Because we currently only modify a single configuration object per
transaction, we introduce the parse_and_commit_conf() wrapper around
parse_and_set_conf() to remove duplicated code that would ensue from
calling the latter directly, namely, releasing the 'mac_do_rwl' lock and
freeing the old configuration object (if any).


    [11 lines not shown]
DeltaFile
+76-23sys/security/mac_do/mac_do.c
+76-231 files

FreeBSD/src d344d17sys/security/mac_do mac_do.c

MAC/do: Support for atomically modifying configurations

As mentioned in previous commits "MAC/do: parse_and_set_conf(): Require
the model configuration" and "MAC/do: Sequential consistency for
configuration retrieval", the introduction of the "executable path"
feature, more fundamentally, the fact that there is now more than one
per-jail parameter and that parameters can be independently modified or
copied, causes an atomicity problem in case of concurrent accesses to of
a jail's applicable configuration.

Partially modifying a configuration is indeed akin to
a read-modify-write operation, where the read is either to the current
or an inherited configuration.  More precisely, once pointed to by
a jail, a configuration object is immutable, and changing the jail's
configuration means making the jail point to another configuration
object.  To change a jail's configuration, a new configuration object is
thus built, and if only some parameters have been explicitly specified,
those that have not been are set by copying the corresponding values
from an existing configuration object (in case of partial modification

    [36 lines not shown]
DeltaFile
+49-15sys/security/mac_do/mac_do.c
+49-151 files

FreeBSD/src 84af2a5sys/security/mac_do mac_do.c

MAC/do: Sequential consistency for configuration retrieval

Since the inception of mac_do(4), find_conf(), used to retrieve the
applicable configuration, has been weakly consistent with respect to
concurrent modifications to configuration inheritance that influence its
result (and it has been sequentially consistent with respect to other
configuration modifications, which the initial executable paths feature
and introduction of implicit parameters broke and which will be fixed in
a subsequent commit).

Indeed, find_conf() climbs the jail tree to find an applicable
configuration, which is not an atomic operation.  It examines the
current jail's configuration pointer for each browsed jail, which does
not prevent concurrent modifications of the configuration pointer for
jails below or above it.  Modifications above the current jail are not
a problem, since if climbing needs to continue (i.e., the current jail
inherits), these modifications will be seen if performed before that
check (and may or may not be seen if performed after that check).
However, modifications below the current jail impair sequential

    [50 lines not shown]
DeltaFile
+69-53sys/security/mac_do/mac_do.c
+69-531 files

FreeBSD/src a6398c2sys/security/mac_do mac_do.c

MAC/do: Comment to explain the main invariant for configurations

Once visible, configuration structures must *never* change.

Spell that out in a comment to help future readers/contributors
understand the design.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

(cherry picked from commit 5bedb5e44757ba83dba9d618f5b951416cf44345)
DeltaFile
+5-0sys/security/mac_do/mac_do.c
+5-01 files

FreeBSD/src ddad099sys/security/mac_do mac_do.c

MAC/do: Allocate only one default configuration

When mac_do(4) is loaded, all jails get the same default configuration
(disabled, with only one allowed executable path: '/usr/bin/mdo').
Share it between all jails instead of creating a separate copy for each.

Reviewed by:    bapt
Fixes:          9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

(cherry picked from commit 31ef4ee2e3570b8f438b9b3fb09b3d87c87419ff)
DeltaFile
+12-12sys/security/mac_do/mac_do.c
+12-121 files

FreeBSD/src d0ff872sys/security/mac_do mac_do.c

MAC/do: Visually separate some file sections

With additional empty lines.

No functional change (intended).

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

(cherry picked from commit 01e2b0ce1820adf475e372ec72371dffca17a7af)
DeltaFile
+2-0sys/security/mac_do/mac_do.c
+2-01 files

FreeBSD/src ab2f2f1sys/security/mac_do mac_do.c

MAC/do: Fix reporting of "mac.do" post-"executable paths"

In mac_do_jail_get(), computation of 'jsys' had not been updated to take
into account executable paths.

Reviewed by:    bapt
Fixes:          9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

(cherry picked from commit 888a84ceeded9ef69903e352827cdef58163027e)
DeltaFile
+2-3sys/security/mac_do/mac_do.c
+2-31 files

FreeBSD/src 31d9802sys/security/mac_do mac_do.c

MAC/do: Configuration: Fix default values: Remove jail creation method

mac_do_jail_create() would create a default configuration on the
just-created jail, erroneously causing mac_do_jail_set() to then
retrieve it and use it as a model when determining the default values
for not-specified parameters, instead of using the configuration
applicable to the parent jail.

Setting a default configuration in mac_do_jail_create() had been done as
a kind of defensive measure to prevent a created jail not to have
a configuration (effectively making it inherit from an ancestor jail,
which is a security hazard except if explicitly requested).  However,
this measure was never really effective (osd_jail_call(PR_METHOD_CREATE)
in kern_jail_set() calls the PR_PETHOD_CREATE methods in an unspecified
order, and stops at the first error), so we are forced to rely in any
case on the fact that an error in a PR_METHOD_CREATE or PR_METHOD_SET
method leads to stopping the jail creation process (which is the case
today; see kern_jail_set()).


    [7 lines not shown]
DeltaFile
+6-14sys/security/mac_do/mac_do.c
+6-141 files

FreeBSD/src e764038sys/security/mac_do mac_do.c

MAC/do: Fix the recent logic to set jail parameters, make it more tolerant

The logic introduced in the initial commit for the "executable paths"
feature did not match the specification we discussed in that specifying
an empty value (for rules or executable paths) on "mac.do" being "new"
would be treated as an absence of value and trigger a copy from the
currently applicable configuration, instead of being an override that
deactivates mac_do(4) in the jail.  Fix that by distinguishing both
cases.

More generally, a non-explicitly specified parameter is set to the same
value it has in the currently applicable configuration (that of the
closest ancestor jail that has one; 'prison0' (the host) always has
one), with an exception in the disable case.

On disable (explicit: "mac.do" to "disable", implicit: no parameters
passed, or at least one is empty), now accept parameters with
a non-empty value as long as at least one of them is empty (which alone
is enough to disable mac_do(4)).  If no parameters are passed, both are

    [26 lines not shown]
DeltaFile
+145-66sys/security/mac_do/mac_do.c
+145-661 files

FreeBSD/src b338e09sys/security/mac_do mac_do.c

MAC/do: Constify is_null_or_empty()

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

(cherry picked from commit 37bc08d5fe9933f41574bf477080d729daf19928)
DeltaFile
+1-1sys/security/mac_do/mac_do.c
+1-11 files

FreeBSD/src 67ec8dbsys/security/mac_do mac_do.c

MAC/do: Fix obsolete wording in a comment ("ascendant" => "ancestor")

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

(cherry picked from commit dbf8f0895ad86fea10adbd678873f8af0bd7558c)
DeltaFile
+1-1sys/security/mac_do/mac_do.c
+1-11 files

FreeBSD/src 619213csys/security/mac_do mac_do.c

MAC/do: parse_and_set_conf(): Require the model configuration

This change is a prerequisite for the next change in caller
mac_do_jail_set(), which for semantic correctness needs to rely on
a stable model configuration.

The two other callers already call find_conf() to retrieve the
applicable configuration, so for these a second call to find_conf() can
be saved.

However, this does not fix (actually, makes slightly worse) an atomicity
problem when multiple threads concurrently change some jail's
configuration (or the configuration inherited by a jail), which has
existed since the introduction of executable paths due to being able to
change only rules or executable paths independently (and the possibility
of not specifying them and having them copied from the currently
applicable configuration).  Before tackling it in later commits, we
first focus on fixing the semantics of configuration changes in the very
next patches.

    [7 lines not shown]
DeltaFile
+38-28sys/security/mac_do/mac_do.c
+38-281 files

FreeBSD/src 0466e93sys/security/mac_do mac_do.c

MAC/do: parse_and_set_conf(): Obey empty parameters; Add doc

parse_and_set_conf() is meant to be used in all situations when there is
a need to set or modify some jail's MAC/do configuration.  This entails
passing the information of whether some parameter was explicitly
specified.  For example, an administrator setting/modifying jail
parameters may not specify executable paths but only rules, in which
case the executable paths value is copied from the currently-applicable
configuration.  The sysctl(8) knobs case always leverages this feature,
since setting a knob changes one parameter at a time.

Currently, a NULL or empty string argument is treated as a non-specified
parameter.  This causes a bug where disabling MAC/do in a jail does not
actually work because, to this end, parse_and_set_conf() is passed an
empty string which it then interprets as a request to copy the currently
applicable configuration's value, which may well not be empty.

Fix this problem by only treating NULL as a marker for a non-specified
parameter, in accordance with the original design for this function.

    [13 lines not shown]
DeltaFile
+14-14sys/security/mac_do/mac_do.c
+14-141 files

FreeBSD/src ce8846dsys/security/mac_do mac_do.c

MAC/do: Remove superfluous configuration initialization

Configuration objects would be initialized (zeroed, and some
STAILQ_INIT() called) multiple times.  Make sure they are so only once,
and add assertions to check that this is actually the case for functions
that expect it.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

(cherry picked from commit 11b567e94ad2a1b4baf768d77c6f1fb2018cfe83)
DeltaFile
+24-10sys/security/mac_do/mac_do.c
+24-101 files

FreeBSD/src bef2b6esys/security/mac_do mac_do.c

MAC/do: clone_rules(): Readability improvements, constification

Constify in order to let the compiler check that source and destination
arguments are passed in the proper order in the different calls.

No functional change (intended).

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

(cherry picked from commit ce59a4181593f59028d3a26f2b63dcf2c8041d79)
DeltaFile
+13-11sys/security/mac_do/mac_do.c
+13-111 files

FreeBSD/src c8394ffsys/security/mac_do mac_do.c

MAC/do: Move static assertions on constants close to their definitions

And document more clearly their purpose.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

(cherry picked from commit 4e27cc086b3f9e029160da8830abacb06a2f9e39)
DeltaFile
+6-4sys/security/mac_do/mac_do.c
+6-41 files

FreeBSD/src e4ab958sys/security/mac_do mac_do.c

MAC/do: Fix releasing a nonexistent reference on configuration parsing error

On parsing error, parse_and_set_conf(), introduced with the recent
"executable paths" feature, has been calling drop_conf() on the
being-built configuration.  However, that configuration structure is
allocated through alloc_conf(), which does not grab a reference.
Calling drop_conf() on it, which releases a reference, is thus
erroneous, and causes the underlying counter to saturate, translating
into a memory leak.

To fix this bug, make alloc_conf() grab a reference on the newly-created
'struct conf', and rename it to new_conf() to be more in line with what
it does.  Keep set_conf() as is, i.e., grabbing an additional reference
on behalf of the jail that is going to hold the configuration.
Consequently, make sure that callers of alloc_conf() unconditionally
drop the reference acquired by the latter before returning (i.e., even
if set_conf() has been called).

While here, since hold_conf() is always used to obtain additional

    [17 lines not shown]
DeltaFile
+10-6sys/security/mac_do/mac_do.c
+10-61 files

FreeBSD/src c0f6eafsys/security/mac_do mac_do.c

MAC/do: Constify clone_rules() and clone_exec_paths()'s source argument

Defensive programming.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

(cherry picked from commit 68cc6aa2e93a2a2969eb40b5588452eeb1805fa6)
DeltaFile
+3-2sys/security/mac_do/mac_do.c
+3-21 files

FreeBSD/src 56e1a62sys/security/mac_do mac_do.c

MAC/do: find_conf(): Return configuration with a true reference

In addition to the applicable configuration, find_conf() was returning
a pointer to the actual jail holding the configuration object, with that
jail's mutex locked in order to ensure liveness of the returned
configuration (if we wouldn't, a concurrent thread modifying the jail's
configuration could destroy this configuration object underneath us).

But:
1. Ensuring configuration stability by owning the holding jail's mutex
   requires callers to either keep that mutex locked for a longer period
   of time than just accessing the corresponding 'struct prison' (in
   general, bad for concurrency with other operations involving jails)
   or to perform an additional dance to acquire a real reference in case
   the jail's mutex, for some reason (in general, LORs or acquiring
   a sleepable lock) must be dropped before use.
2. Most code does not actually need to know which jail holds the
   applicable configuration but for unlocking the jail's mutex.  Having
   to deal with the jail holding the configuration can cause confusion

    [21 lines not shown]
DeltaFile
+40-43sys/security/mac_do/mac_do.c
+40-431 files

FreeBSD/src e3373e0sys/security/mac_do mac_do.c

MAC/do: find_conf(): Turn an MPASS() into a KASSERT()

Turn the pre-existing comment into an assertion message, with an update
following the introduction of the "executable paths" feature.

Explain in a comment why this situation cannot happen.

Without INVARIANTS, such a situation would cause an immediate panic()
(NULL is dereferenced in the next iteration of the loop), so leave the
check under INVARIANTS only.

Reviewed by:    bapt
MFC after:      1 month
Sponsored by:   The FreeBSD Foundation
Pull Request:   https://ron-dev.freebsd.org/FreeBSD/src/pulls/38

(cherry picked from commit cf942ac9e967055286a7076bf76e9a62e1d22d8f)
DeltaFile
+9-1sys/security/mac_do/mac_do.c
+9-11 files