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

[Martin Kelly]

On Thu, Nov 5, 2026 at 4:26 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> This seems weird; your task-B bpf prog would never run due to the
> prog_active thing.

Sorry, I misspoke a bit. The issue we hit was a per-CPU array shared
across different programs. Since prog->active is per program, this
wasn't safe once programs were preempted.

> You've not mentioned your CONFIG_HZ setting? Anyway, something daft like
> the below would make promotion less aggressive (also, clearly I couldn't
> come up with a decent name for the intermediate step :-).

The 7.1.5 system we tested had the below settings. The 7.0.9 system was
the same other than CONFIG_HRTIMER_REARM_DEFERRED.
CONFIG_HRTIMER_REARM_DEFERRED=y
CONFIG_PREEMPT_LAZY=y
CONFIG_PREEMPT_DYNAMIC=y
CONFIG_PREEMPT_RCU=y
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y

The 7.1.5 system also had these:
$ cat /sys/kernel/debug/sched/preempt
full (lazy)
$ grep -oE '(NO_)?HRTICK(_DL)?' /sys/kernel/debug/sched/features
HRTICK
HRTICK_DL

> I would strongly prefer all BPF programs that attach to known
> preemptible sites to use a per-task recursion counter or something of
> that sort.

I agree; it seems to me with per-task + per-prog tracking, we could have
arbitrary preemption without recursion_misses. The question is how to
implement this efficiently.

> ---
> diff --git a/include/asm-generic/thread_info_tif.h b/include/asm-generic/thread_info_tif.h
[...]

We will test this with and without HRTICK on and let you know what it
does to the miss rates.

Thanks,
Martin