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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] bpf: bpf_call_rcu_tasks_trace() deadlock from NMI context
--

commit 47fa2f5e11782172e769349f78bd62857f9572eb
Author: Puranjay Mohan <puranjay@kernel.org>

bpf: Add bpf_call_rcu_tasks_trace() kfunc

This commit introduces the bpf_call_rcu_tasks_trace() kfunc to allow
sleepable BPF programs to safely defer reclaim using a tasks trace RCU
grace period. It shares verifier plumbing and struct bpf_rcu_head with
bpf_call_rcu(), differing only in the queueing call.

> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -4872,13 +4861,50 @@ __bpf_kfunc int bpf_call_rcu(struct bpf_rcu_head *rh, void *map__const_map,
[ ... ]
> -	rhk->callback_fn = (bpf_callback_t)(void *)callback;
> +	rhk->callback_fn = (bpf_callback_t)callback;
>  	rhk->map = map;
>  	rhk->prog = prog;
> -	call_rcu(&rhk->rcu, bpf_rcu_run_callback);
> +	if (trace)
> +		call_rcu_tasks_trace(&rhk->rcu, bpf_rcu_run_callback);
> +	else
> +		call_rcu(&rhk->rcu, bpf_rcu_run_callback);
>  	return 0;
>  }

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

If a BPF tracing program executing in NMI context (or with IRQs disabled)
calls the bpf_call_rcu_tasks_trace() kfunc, it will unconditionally invoke
call_rcu_tasks_trace(), which is a wrapper for call_srcu().

Since call_srcu() requires acquiring a raw_spinlock_t (sdp->lock), if the
NMI interrupted a task on the same CPU that was already holding this
spinlock, the NMI handler will spin indefinitely attempting to acquire it.

Should this code defer call_rcu_tasks_trace() via irq_work_queue if
irqs_disabled() is true, similar to how it is handled in
bpf_async_refcount_put()?

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