Re: [EXT.MSG] Re: [PATCH RFC bpf-next 0/2] bpf: Do not let preemption cause false recursion drops in trampoline progs

[Alexei Starovoitov]

On Tue, Nov 03, 2026 at 01:28 PM Mike Bazov <mikeba@xxxxxxxxxxxxxxx> wrote:
> Thanks! fsession does keep entry and exit consistent. It doesn't recover
> the skipped runs though. I ran the selftest scenario with an fsession
> prog on __set_task_comm (7.0 kernel, lazy preemption, 20 rounds): Task
> B's entry and exit runs were both skipped in every round (entry_b=0,
> exit_b=0, recursion_misses=40), since each run still goes through
> prog->active while Task A is preempted mid-program.

Right.
fsession fixes the pairing. It doesn't fix the miss.

> What is the main obstacle to per-task tracking?

Today a fentry prog never runs twice at the same time on one cpu.
Existing progs rely on that for their per-cpu maps.

  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

A plain (*cnt)++ in a per-cpu map loses updates the same way.
Today B is skipped and recursion_misses counts it.
With the per-task check A sends a corrupted event and nothing counts it.

> And if per-task is not an option, do you have another approach
> in mind so that runs of unrelated tasks are not skipped?

Add bpf_preempt_disable().
Your test forces the preemption in the middle of the prog.
Explicit bpf_preempt_disable() will fix it.
And you'll have an easy way to see why disabling preemtion
for the whole program might hurt your own production.

What are run_cnt and recursion_misses of your progs on inet_sendmsg()
and inet_recvmsg() in production?