bpf: Fix conditions when timer/wq can be called

[kernel-patches-daemon-bpf]

Pull request for series with
subject: bpf: Tighten conditions when timer/wq can be called synchronously
version: 2
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=1050571

[kernel-patches-daemon-bpf]

Upstream branch: b28dac3
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1050571
version: 2

[kernel-patches-review-bot]

commit b291642856eae07d97b701836aab6c85d97bedc7
Author: Alexei Starovoitov <[email protected]>

bpf: Add a recursion counter to prevent loops in bpf_timer

This commit adds a per-CPU counter to prevent recursive timer/wq operations
when the CPU is already processing the async_cmds queue in the irq_work
callback.

> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index 0517e9a8f..0f681a89b 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -1427,9 +1427,21 @@ static int bpf_async_update_prog_callback(struct bpf_async_cb *cb,
>  	return 0;
>  }
>
> +static DEFINE_PER_CPU(int, async_cb_running);
> +
>  static int bpf_async_schedule_op(struct bpf_async_cb *cb, enum bpf_async_op op,
>  				 u64 nsec, u32 timer_mode)
>  {
> +	/*
> +	 * Do not schedule another operation on this cpu if it's in irq_work
> +	 * callback that is processing async_cmds queue. Otherwise the following
> +	 * loop is possible:
> +	 * bpf_timer_start() -> bpf_async_schedule_op() -> irq_work_queue().
> +	 * irqrestore -> bpf_async_irq_worker() -> tracepoint -> bpf_timer_start().
> +	 */
> +	if (this_cpu_read(async_cb_running))
> +		return -EDEADLK;

Does this early return leak a reference? Looking at the callers:

bpf_timer_start() does:

    if (!refcount_inc_not_zero(&t->cb.refcnt))
        return -ENOENT;
    ...
    return bpf_async_schedule_op(&t->cb, BPF_ASYNC_START, nsecs, mode);

The refcount is incremented before calling bpf_async_schedule_op(). The
existing -ENOMEM path in bpf_async_schedule_op() releases this refcount:

    if (!cmd) {
        bpf_async_refcount_put(cb);
        return -ENOMEM;
    }

But the new -EDEADLK path returns without calling bpf_async_refcount_put(cb).

The same issue affects bpf_wq_start() and bpf_timer_cancel_async(), which
also increment the refcount before calling bpf_async_schedule_op().

> +
>  	struct bpf_async_cmd *cmd = kmalloc_nolock(sizeof(*cmd), 0, NUMA_NO_NODE);
>
>  	if (!cmd) {

[ ... ]

---

AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

In-Reply-To-Subject: bpf: Add a recursion counter to prevent loops in bpf_timer
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21658239378

AI-authorship-score: low
AI-authorship-explanation: The commit follows established kernel conventions, comes from a known BPF maintainer, and addresses a real technical issue with code patterns typical of experienced kernel developers.
issues-found: 1
issue-severity-score: medium
issue-severity-explanation: The new -EDEADLK error path does not release the refcount taken by callers, leading to reference leaks that can cause memory exhaustion over time.

[kernel-patches-daemon-bpf]

Forwarding comment 3845171225 via email
In-Reply-To: [email protected]
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/

[kernel-patches-daemon-bpf]

At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=1050571 irrelevant now. Closing PR.