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

From: Martin Kelly

Date: Thu Nov 05 2026 - 15:29:49 EST


On Wed, Nov 4, 2026 at 9:18 PM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
> what do you mean? the reentrance prevention counter works on PREEMPT_RT too.
> per-cpu array are not corrupted there.

Sorry, I should have been clearer. The issues we hit were with using a
single per-CPU array across multiple *different* trampoline programs,
not a single program exclusively using a given per-CPU array. The
verifier doesn't prevent this, and we hit it on RT kernels, where
trampolines have always been preemptible. On 7.0+, this issue is likely
now exposed on non-RT kernels too. The per-CPU issue doesn't affect us
since we stopped using per-CPU arrays, but the recursion_misses still
do. Since prog->active is per program, the per-CPU exclusivity only
applied within a single BPF program, not across programs sharing
maps (which is very common).

> Thanks for the numbers.
> Are you saying turning off HRTICK is not an option for your production?

We support many different Linux distros, so we have to work with what
the vendor provides and cannot change CONFIG_ values. Since it's now the
default, it's starting to be used by distros, which is why we're
noticing the issue now. Changing it dynamically is up to the customer,
and if we changed it on their behalf, it could affect their other
workloads. Debugfs is also not always mounted, and it still wouldn't
help with the increased drops on 7.0 kernels, since we have misses there
even with HRTICK off (1 in 61,580 on security_file_permission in the
above data).