Commit fixes provided by Chuck Cranor, thank you very much.
The fixes correct color handling glitches which were the result of
the terminal colour incorrectly being reset to the original pair not
the default color that had been set.
Install the manhtml obsolete set.
While here, remove some files from it that are not actually obsolete,
but in the comp set.
I don't understand the logic for putting files in one or the other,
someone who does: please review them.
Pass a number of bpf_insn to npf_bpf_compile, this should fix kern/60975.
Contrary to what the PR says, it broke loudly only in -current
when I tightened checks in bpfjit_generate_code on July 5th, 2026.
In stable releases it reads past the end of allocations but it generates
valid jitted code.
Why it works in stable releases:
- bpf_validate() checks that a rule ends with a valid RET and
that jumps don't jump past the last RET,
- bpfjit in stable releases doesn't check for a valid RET, it
relies on bpf_validate().
- bpfjit starts by (over)allocating a shadow bpfjit_insn array,
then scans (and goes past the end) instructions, builds CFG
and sets the "unreachable" flag in the shadow array. All
instructions after the last RET have unreachable set to true.
- bpfjit skips emitting any code when unreachable is true
[5 lines not shown]
Use proper naming for registering ether filtering hooks
get_etherpfil_head function name doesn't make sense in that context.
use register_etherpfil_hooks (plural) which registers one hook
(by calling the singular form (register_etherpfil_hook)
per interface at the ether layer.
No functional change intended
Thanks Edgar Fub
set lists: remove support for openssl < 3.5
Should fix 'obsolete' state of quite a number of files
ok riastradh
While here, remove some files that were listed in two sets from one.
x86/efi(4): Set up pcb_onfault handler during efirt access to abort.
This way, if buggy firmware crashes, we have a chance of gracefully
recovering instead of crashing the kernel -- same as we already do on
arm.
PR kern/59235: efi(8) panics
linux ww_mutex: Nix another assertion that trips in sketchy path.
Under the premise (explained in the comment above) that it is
legitimate for the upstream Linux code to do ww_mutex_trylock on a
mutex already held by the current thread, we can't assert
mutex->wwm_state != WW_WANTOWN ||
mutex->wwm_u.ctx->wwx_owner != curlwp
any more than we can assert
mutex->wwm_state != WW_CTX ||
mutex->wwm_u.ctx->wwx_owner != curlwp
because if the latter condition is possible, then any concurrent
thread tries to acquire the mutex a moment before we test that
condition will turn it into the former condition, i.e., transition to
mutex->wwm_state = WW_WANTOWN with mutex->wwm_u.ctx->wwx_owner =
curlwp.
[3 lines not shown]
efi(4): Fix off-by-one error and use sizeof to clarify this logic.
Found by mlelstv@ while investigating (but will not fix):
PR kern/59235: efi(8) panics
Define and use an INIT_KSP() macro that initializes the kernel stack
pointer with a value from the specified register and also ensures the
stack frame chain is terminated by setting %a6 to 0.
comp: remove binutils=234 support; mark files unconditionally obsolete
They were only marked as obsolete for 239, and we're at 242 now,
and they're still obsolete.
nouveau: Don't set dma fence error if already signaled.
This happens asynchronously on hardware error. Upstream Linux trips
WARN_ON in this case; our dma_fence_set_error trips KASSERT instead.
We could maybe switch dma_fence_set_error to use WARN_ON too but it's
probably better not to take this path anyway -- this assertion trips
on logic that is incoherent, if not outright wrong.
PR kern/58745: nouveau triggered assert in linux_dma_fence.c
drm: Fix rcu_replace_pointer.
This Linux API macro takes an _lvalue_ expression for an object, not
a pointer to the object -- unlike, e.g., the atomic_load/store
functions. So we can't copy its value into a local variable (to
avoid duplicate macro argument expansion) and then assign the local
variable with rcu_assign_pointer because that will only modify the
local copy, not the caller's lvalue!
Rename the macro parameters to make this clearer so it doesn't trip
me up again next time I read this.
Probably fixes dozens of graphics problems on a generation of Intel
hardware. Derp!
PR kern/60980: rcu_replace_pointer() fails to update the original pointer
Don't bother setting -fno-omit-frame-pointer if PROF is set; the in-tree
GCC now does the right thing with instrumented function frames regardless
of command line options.
