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"))).
rump: Copy struct proc::p_pgrp explicitly
Now that it's not in p_startcopy/endcopy, the memcpy isn't enough.
Should fix the thousands of test failures I caused by moving p_pgrp
out of the p_startcopy/endcopy range!
PR kern/60962: fork and spawn read p_pgrp without proc_lock
Fix broken NPF BPFJIT tests.
when compiling BPF byte code, bpf_jit_generate_code called by npf_bpf_compile
expects the size in array count not the raw byte size of the bpf instruction struct.
also, use npf's kernel prepare function to initialize the byte code args.
