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

[Mike Bazov]

On Wed, Nov 04, 2026 at 02:20 AM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
   > Add bpf_preempt_disable().
   > Your test forces the preemption in the middle of the prog.
   > Explicit bpf_preempt_disable() will fix it.

   I tried it, and with the whole prog body wrapped in bpf_preempt_disable() /
   bpf_preempt_enable(), Task B is still skipped in every round (on a 7.0
   kernel, 20 rounds, fentry and fexit: runs_b=0, recursion_misses=20).

   perf record -e sched:sched_switch -g shows where Task A is switched out
   now, 20 of 20 (Task A, SCHED_OTHER, preempted by Task B, SCHED_FIFO):

     __schedule+0x48f
     preempt_schedule+0x59
     preempt_schedule_thunk+0x16
     bpf_preempt_enable+0x1c
     bpf_trampoline_6442539626+0x105
     bpf_prog_7dd04eadc26e277d_on_fentry+0x11
     bpf_trampoline_6442539626+0x192
     __set_task_comm+0x5

   That is still inside the prog, while prog->active is held.

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

   We hit this while testing new distros with 7.0 kernels, so we don't
   have fleet numbers for these counters yet. For our inet_sendmsg/recvmsg
   progs, in testing: fentry/fexit on inet[6]_{send,recv}msg, Ubuntu 24.04
   with its stock 7.0 HWE kernel (7.0.0-38-generic, default lazy
   preemption, 4 vCPUs), behind nginx -> gunicorn -> redis, with wrk from
   another machine (128 keep-alive connections, ~1.07M requests over 10
   minutes, ~62% CPU):

     run_cnt 38040015, recursion_misses 4063