ld.elf_so: Fix one more mistake in handling _rtld_load_object.
This can return NULL (meaning object not found or something went wrong
with the object) or OBJ_ERR (meaning the object has DF_1_NOOPEN set or
the caller passed RTLD_NOLOAD to dlopen() and the object was not
already loaded) or a valid object.
I reviewed all paths out of _rtld_load_object to make sure they
gracefully handle all three cases (NULL, OBJ_ERR, valid object), and
this assertion was the only path that didn't.
Fixes buggy assertion added for:
PR lib/59751: dlclose is not MT-safe depending on the libraries
unloaded
May fix:
PR bin/60472: ld.elf_so(1) changes cause a segmentation fault in
dlopen(3)
[flang] Lower initial values via ConvertConstant instead of the legacy expression lowering (#210621)
Global and component initial values were lowered with
`createSomeInitializerExpression` (the legacy, non-HLFIR expression
lowering). Route them through ConvertConstant instead, which is
self-contained and safe inside a fir.global initializer region: it never
consults the symbol map, allocates temporaries, or outlines constants
into memory.
Observable IR change: fir.no_reassoc no longer appears in fir.global
initializer regions for parenthesized scalar/derived constants. Update
global-initialization-parens.f90 -- previously a pre-commit baseline
pinning the old fir.no_reassoc behavior -- to assert the new folded
form, and add common-block-derived-initialization.f90 (a
DATA-initialized common block with a derived-type member).
Assisted-by: AI
graphics/xournalpp: Replace /proc/self/exe with the FreeBSD equivalent
Some people reported that xournalpp fails to start, but I couldn't
reproduce this for some reason before this fix. It worked fine for me
every time I used it.
PR: 295834
Reported by: Julian Ospald <hasufell at posteo.de>
nginx: Update to 1.30.4
Changes with nginx 1.30.4 15 Jul 2026
*) Security: heap buffer overflow might occur in a worker process when
using the map directive with regex matching if the map variable was
included in a string expression after a capture affected by this map;
a similar issue might happen when using a non-cacheable variable in a
string expression (CVE-2026-42533).
Thanks to Mufeed VH of Winfunc Research and Maxim Dounin.
*) Security: uninitialized memory access might occur when using unnamed
regex captures with the "slice" directive or background cache update,
which could result in worker process memory disclosure or worker
process termination (CVE-2026-60005).
*) Security: use-after-free might occur when processing a specially
crafted proxied backend response with the ngx_http_ssi_filter_module
(CVE-2026-56434).
Thanks to P4P3R-HAK.
[flang][OpenMP] Lower iterator indices with genExprValue instead of the legacy expression lowering (#210385)
`getIteratorElementIndices()` lowered the depend/affinity iterator
subscript expressions with `createSomeExtendedExpression` (the legacy,
non-HLFIR expression lowering). Switch it to
`AbstractConverter::genExprValue`, matching the idiom already used
elsewhere in OpenMP/Utils.cpp, so this code no longer depends on the
legacy expression lowering.
The iterator LIT tests are updated to reflect the induction values now
being materialized in memory (store + hlfir.declare + load) and the
subscript arithmetic lowering through HLFIR (hlfir.no_reassoc instead of
fir.no_reassoc).
Assisted-by: AI
ena: Put taskqueues into correct domain if !RSS
When compiled without 'options RSS', the ena driver created taskqueues
using taskqueue_start_threads_cpuset passing a mask value of NULL,
both in the ena_setup_tx_resources path (for enqueues) and in the
ena_create_io_queues path (for the completion-processing).
In the default configuration, on most EC2 instances, this results in
taskqueues running in the right NUMA domain, but only by accident; in
non-default configurations (e.g. with with multiple EBS volumes
attached and associated NVMe taskqueues) the taskqueues may land in
the wrong NUMA domain even on instance types where the one-EBS-one-ENA
case produces the desired results.
Set (struct ena_que)->domain and use that to inform the choice of CPU
sets. On a c8gn.48xlarge EC2 instance this doubles throughput on a
32-TCP-stream benchmark.
Reviewed by: akiyano
[5 lines not shown]
ena: Put taskqueues into correct domain if !RSS
When compiled without 'options RSS', the ena driver created taskqueues
using taskqueue_start_threads_cpuset passing a mask value of NULL,
both in the ena_setup_tx_resources path (for enqueues) and in the
ena_create_io_queues path (for the completion-processing).
In the default configuration, on most EC2 instances, this results in
taskqueues running in the right NUMA domain, but only by accident; in
non-default configurations (e.g. with with multiple EBS volumes
attached and associated NVMe taskqueues) the taskqueues may land in
the wrong NUMA domain even on instance types where the one-EBS-one-ENA
case produces the desired results.
Set (struct ena_que)->domain and use that to inform the choice of CPU
sets. On a c8gn.48xlarge EC2 instance this doubles throughput on a
32-TCP-stream benchmark.
Reviewed by: akiyano
[5 lines not shown]
kern/sys_ptrace: do not skip P2_PTRACEREQ wait for PT_CLEARSTEP/PT_GET_CHILDREN
Reported and reviewed by: markj
Fixes: d3b7bbee9275 ("ptrace(2): add PT_GET_CHILDREN")
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58364
[clang] Use 0 for wasm_funcref in non-Wasm address space maps (NFCI) (#210253)
The __funcref keyword is only supported by the WebAssembly target, so
the wasm_funcref entries in other targets' address space maps are
unused.
Use 0 for these entries, which is consistent with other unsupported
address spaces.
sched_4bsd: Allocate runqueues only for present CPUs
4BSD has been allocating an array of MAXCPU runqueues, runq_pcpu[],
instead of one runqueue per actually present CPU. On amd64, MAXCPU is
1024 and 'struct runq' is 4128 bytes, causing runq_pcpu[] to take more
than 4 MiB of memory. On the vast majority of current systems, which
have at most 32 cores with SMT, this is a waste of memory.
Besides providing per-CPU runqueues, runq_pcpu[] has also been used to
determine the CPU ID of a given thread's associated runqueue through
pointer arithmetic.
Since per-CPU structures are only allocated for present CPUs, in order
to save space, move the runqueues to per-CPU fields and, for each thread
('struct ts_sched'), replace its runqueue pointer by the CPU ID of the
runqueue it is in (new 'ts_rqcpu' field). Set the thread's CPU ID to
the special NOCPU value when it is running on the global runqueue.
Drop the SKE_RUNQ_PCPU() macro as it is now simply equivalent to
[11 lines not shown]
sched_4bsd: Rename the global runqueue
In an upcoming change whose purpose is to stop having 4BSD always
allocate MAXCPU runqueues, wasting space on most machines, 'struct
td_sched' will store the CPU ID to which a thread is bound/pinned
instead of a pointer to the corresponding runqueue. As a consequence,
existing functions manipulating a thread's runqueue will need to point
to the inferred runqueue through a local variable. The name 'runq' is
the ideal one for these local variables, but before this change it
designated the global runqueue, also causing unnecessary ambiguity.
Thus, rename the global runqueue to the more explicit 'runq_global'.
Arguably, this should have been performed as part of commit e17c57b14ba9
("- Implement cpu pinning and binding. (...)").
No functional change (intended).
[olce: Massaged the commit message. Tested with source builds.]
[5 lines not shown]
sched_4bsd: Remove obsolete SMP scaling for ticks per priority level
The INVERSE_ESTCPU_WEIGHT scaling had been introduced by commit
b698380f33ef ("Quick fix for scaling of statclock ticks in the SMP
case. ...") to leave more discrimination room for multiple CPUs possibly
adding their ticks to the same 'struct ksegrp' (but also slightly
changing how CPU hogs are penalized).
Then, commit 8460a577a4b4 ("Make KSE a kernel option, ...") introduced
the current thread-based code, where tick accounting is only done on the
current thread, which renders this trick obsolete on !KSE.
Finally, when KSE was removed, the trick became generally obsolete.
The trick is actually even harmful because it changes the intended
behavior of priorizing more the CPUs that use the less ticks (and so,
impairs boosting "interactive" processes).
Remove it now. Clamping of 'ts_estcpu' and its relation to the
[6 lines not shown]
sched_4bsd: Fix conflating priority of differently-niced CPU-bound threads
We introduced (PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE) as part of
ESTCPULIM() in commit eebc148f25c3 ("sched_4bsd: ESTCPULIM(): Allow any
value in the timeshare range") in order to use more than a fixed number
(40) of all the available priority levels in the timeshare range (136
before the 256-queue runqueue work, 224 now) to take into account the
number of ticks a thread has run ('ts_estcpu').
In the computation of a new thread's priority (resetpriority()), in
addition to the "ticks running" contribution, the final priority also
includes a "nice" value contribution. The final value is clamped into
the [PRI_MIN_TIMESHARE; PRI_MAX_TRIMESHARE] range.
Problem is that the new "ticks running" contribution now can lead to
a computed priority value that exceeds PRI_MAX_TRIMESHARE, and is thus
finally clamped to PRI_MAX_TIMESHARE, which becomes an alias for all
out-of-bound values. In particular, this can conflate CPU-hungry
threads. With at least two of them competing on the same CPU, with an
[20 lines not shown]
[lldb][RISCV] Fix x8 register aliasing for gdb-remote targets (#209070)
GDB remote target descriptions can expose the RISC-V `x8` register as
`fp`. LLDB previously used `fp` as the primary name and `s0` as the
alternate name, leaving no register name for `x8`.
This commit changes `s0` as the primary name, `x8` as the alternate
name, and mark the register as the generic frame pointer. Allowing `fp`,
`s0`, and `x8` to resolve to the same register.
Fixes #127900
