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.
More profiling fixes:
- Define NO_PROFILE_COUNTERS=1 and don't emit a profile counter references
in FUNCTION_PROFILER() -- our __mcount() doesn't actually need/use them.
- In SUBTARGET_OVERRIDE_OPTIONS, set flag_omit_frame_pointer=false
if profile_flag is set because our m68k __mcount() relies on standard
m68k stack frames. XXX This is probably better achieved with
{,SUB}TARGET_FRAME_POINTER_REQUIRED, but the m68k back-end doesn't
use that anywhere, so it's a much more invasive change than this.
__mcount() relies on a standard m68k stack frame and the frame pointer for
two things:
1- return address in __mcount()'s frame is used to get selfpc (i.e. the
function being instrumented).
2- __mcount() uses the saved-%fp in its own frame to get the frame pointer
of the instrumented function, which is then used to get return address
in that frame in order to get frompc.
Ensure __mcount()'s stack frame is always set up correctly by decorating
wiht __attribute__((__optimize__("no-omit-frame-pointer"))).
