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 Sat, Oct 31, 2026 at 12:22 AM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
>
> On Sun, Oct 25, 2026 at 04:02 AM Mike Bazov via B4 Relay <devnull+mikeba.sentinelone.com@xxxxxxxxxx> wrote:
>
> > Is disabling preemption in __bpf_prog_enter_recur() on !PREEMPT_RT the
> > preferred fix for fentry/fexit, or would you prefer a different
> > mechanism for reconciling preemptible execution with prog->active and
> > the per-CPU private stack?
>
> No.
> We cannot disable preemption, since progs are not short
> with may_goto they can take 1/4 sec.
>
> Sounds like private stack is the culprit.
> Should we disable it?
>
> pw-bot: cr

I think disabling private stack alone won't stop the false drops by
itself: for fentry/fexit, bpf_prog_check_recur()
is always true even when priv_stack_ptr is NULL (as in the reproducer
and selftest where stack < 64B).

So when Task A is preempted on CPU 0, this_cpu_inc_return(*prog->active)
in __bpf_prog_enter_recur() stays 1 on CPU 0 and skips Task B even when
private stack is not used.

To fix fentry/fexit while keeping preemption enabled, we'll need to:
   1. Disable private stack for fentry/fexit (so each task uses its own
      kernel stack), and
   2. Check recursion in __bpf_prog_enter_recur() per-task rather than via
      the per-CPU prog->active counter (still blocking same-task recursion
      and IRQ/NMI re-entry on the same CPU, while allowing a preempting
      Task B to run).

Does that direction sound good to you for v2?

Regards, Mike