Re: [PATCH bpf-next v3 3/4] bpf: Add bpf_call_rcu_tasks_trace() kfunc

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] bpf: Deadlock risk calling bpf_call_rcu_tasks_trace() from NMI context
- [Medium] API behavior change in bpf_timer/bpf_wq returning -EBADF instead of -ENOENT
--

commit 144bc88aada0f77bf3ad5ba54cb25dc2ae7529ca
Author: Puranjay Mohan <puranjay@kernel.org>

bpf: Add bpf_call_rcu_tasks_trace() kfunc

Sleepable BPF programs hold rcu_read_lock_trace(), not rcu_read_lock(),
so a plain RCU grace period does not wait for them.  A program whose
readers are sleepable needs this flavour to defer reclaim safely.

> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index 6debb92fc8740..b76e2866693af 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -1428,7 +1428,7 @@ static int bpf_async_update_prog_callback(struct bpf_async_cb *cb,
>  	if (prog) {
>  		prog = bpf_prog_inc_not_zero(prog);
>  		if (IS_ERR(prog))
> -			return PTR_ERR(prog);
> +			return -EBADF;
>  	}

[Severity: Medium]
Will this change break backward compatibility for existing BPF programs?

Because bpf_async_update_prog_callback() is shared, this changes the
user-visible return value from -ENOENT to -EBADF when bpf_prog_inc_not_zero()
fails (e.g., when a program's refcount reaches zero).

This affects existing UAPI helpers like bpf_timer_set_callback() and
bpf_wq_set_callback(). Programs relying on the specific -ENOENT error
code for fallback logic might break.

[ ... ]

> +__bpf_kfunc int bpf_call_rcu_tasks_trace(struct bpf_rcu_head *rh, void *map__const_map,
> +					 bpf_rcu_callback_t callback, struct bpf_prog_aux *aux)
> +{
> +	return __bpf_call_rcu(rh, map__const_map, callback, aux, true);
> +}

[Severity: High]
Could this lead to a deadlock if called from NMI context?

The bpf_call_rcu_tasks_trace() kfunc uses call_rcu_tasks_trace(), which maps
to call_srcu(). call_srcu() internally acquires sdp->lock, which is a
raw_spinlock_t.

If a BPF program running in NMI context (such as BPF_PROG_TYPE_PERF_EVENT)
calls this kfunc, and the NMI interrupted a code path that was already
holding the same sdp->lock, the NMI handler will spin forever. Since the
kfunc is exposed without NMI-context restrictions, could a userspace
process able to attach perf events trigger this deadlock?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915143640.36292-1-puranjay@kernel.org?part=3