Re: [PATCH bpf-next v2 0/5] bpf: Check recursion per task for preemptible programs

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Wed, Nov 11, 2026 at 11:39 AM Mike Bazov via B4 Relay <devnull+mikeba.sentinelone.com@kernel.org> wrote:
> This series checks recursion per task instead. Each run already links a
> run context into the task's chain (current->bpf_ctx); the run context
> now records the program, and the check walks the task's chain.

The link walk doesn't look too bad,
but pls share bench trig-fentry/exit/rawtp numbers.
Maybe we should do a per-task array of progs instead to detect recursion?
It's likely more cache efficient than link list walk.

Just for the record here is the illustration of
the case I was concerned about earlier:

  task A, cpu 0                     task B, cpu 0
  buf = lookup(&percpu_scratch)
  fill buf
  <preempted>
                                    buf = lookup(&percpu_scratch)
                                    fill buf
                                    output(buf)
  output(buf)   <- data of B

               today              with the series
  -----------  -----------------  -----------------
  run of B     skipped            runs
  event of A   correct            has the data of B
  who sees it  recursion_misses   nobody

A prog with a scratch map of its own is correct today and
that's what plenty of production bpf progs use today.

This patch set will make them send corrupted events, and nothing counts
this corrupted events. Today, at least, you have a miss count.

Please add it to commit log, so that trade-offs are clear.
Commit log here and in cover letter talk about 'what'.
It needs 'why' and 'trade offs'.

Also should we add an verbose warning to the verifier that
when the tracing prog that uses per-cpu maps might have corrupted
per-cpu data? I know, no one is reading the warnings unless they
are verifier errors, but above scenario really worries me.
I thought about automatic insertion of bpf_preempt_disable() for such lookups
and bpf_preempt_enable() in epilogue.
Maybe that's the way?

> - Timed may_goto keeps its budget per program and CPU, as before: a run
>   in another task can renew the budget of a preempted run.

Not quite.
Today prog->active rejects B before the first insns of the prog.
These insns set count and timestamp.
With the link list approach every B gives A 250 ms more:

  task A, cpu 0                task B, cpu 0
  spins on may_goto
  <preempted>
                               enters the prog:
                               count = BPF_MAX_TIMED_LOOPS
                               timestamp = 0
  spins for 250 ms more

On a hot function A never ends, and it holds rcu_read_lock.
So the promise of may_goto that I just fixed a week or so ago
will be borken again.

pw-bot: cr