Re: [PATCH] bpf: disable lockdep while running BPF on lock_release

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] Disabling lockdep during `trace_call_bpf` for `lock_release` hides valid lock inversions and allows silent physical deadlocks.
- [High] Temporarily disabling lockdep globally via `lockdep_off()` in `trace_call_bpf()` unintentionally blinds lockdep to any hardware interrupts and softirqs that preempt the BPF program.

Pre-existing issues:
- [High] The patch fails to disable lockdep for BPF programs attached to `lock_release` via raw tracepoints.
--

--- Patch [1]: [PATCH] bpf: disable lockdep while running BPF on lock_release ---
commit 4871557897dd6c7f2fd05dc2170475d6e2824a6e
Author: quanyeyang <[email protected]>

bpf: disable lockdep while running BPF on lock_release

trace_lock_release() runs before __lock_release(), so the lock is
still on the held stack when attached BPF programs execute. This patch marks
lock_release with TRACE_EVENT_FL_BPF_NO_LOCKDEP and temporarily disables
lockdep around bpf_prog_run_array() for that event to avoid false recursive
locking warnings.

Closes: https://syzkaller.appspot.com/bug?extid=ef8d17bae14efb960935

> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 75495a5c35079..f2460f3c860e0 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c

[ ... ]

> @@ -144,8 +146,12 @@ unsigned int trace_call_bpf(struct trace_event_call *call, void *ctx)
>  	 * rcu_dereference() which is accepted risk.
>  	 */
>  	rcu_read_lock();
> +	if (no_lockdep)
> +		lockdep_off();

[Severity: High]
Could this introduce a regression by suppressing valid warnings about real
physical lock deadlocks caused by BPF programs?

If a BPF program attached to lock_release acquires a kernel lock, the CPU
physically holds the original lock while executing the BPF program. If the
BPF lock ordering violates the kernel's lock graph, wouldn't this cause a
silent deadlock without any lockdep warning?

[Severity: High]
Could this also introduce a regression by unintentionally blinding lockdep to
hardware interrupts and softirqs?

trace_call_bpf() for lock_release can execute with hardware interrupts
enabled. The lockdep_off() macro increments current->lockdep_recursion.
If a hardware interrupt fires while the BPF program is executing, it runs
in a context where current->lockdep_recursion > 0.

Does this mean all lock acquisitions in the interrupt handler and
subsequent softirqs will completely bypass lockdep tracking?

[Severity: High]
This is a pre-existing issue, but does this approach fail to disable lockdep
for BPF programs attached to lock_release via raw tracepoints?

If a user attaches a BPF program using the raw tracepoint interface
(raw_tracepoint/lock_release), the kernel dispatches this through
__bpf_trace_run() which bypasses trace_call_bpf() completely.

Will the false positive lockdep warning still trigger for raw tracepoints
since they lack this lockdep suppression logic?

>  	ret = bpf_prog_run_array(rcu_dereference(call->prog_array),
>  				 ctx, bpf_prog_run);
> +	if (no_lockdep)
> +		lockdep_on();
>  	rcu_read_unlock();

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260803-fix-lock-tracepoint-bpf-lockdep-v1-1-91fb7afb526a@gmail.com?part=1