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 Fri, Nov 6, 2026 at 2:08 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
> hm, funny how AI figured out run_ctx, but didn't figure out that we
> already chain them and we do have that pointer in current->bpf_ctx...

right, good point, v2 would walk the existing current->bpf_ctx chain instead of
adding a new task_struct pointer

> That's all to say that I don't think there is a need to keep
> guarantees. If per-cpu map is used naively today it works ok most of
> the time, but not all of the time.

Alexei was concerned about existing progs relying on it.

> Perhaps we should just get rid of that whole per-program recursion
> protection and just make sure that a) BPF program can protect itself,
> if necessary

If we drop the recursion check and go with a), protection is up to
each bpf program author, so wouldn't a careless one be able to panic the
kernel? A prog as simple as this one triggers itself:

struct {
      __uint(type, BPF_MAP_TYPE_HASH);
      __uint(max_entries, 1);
      __type(key, int);
      __type(value, long);
} m SEC(".maps");

SEC("fentry/htab_map_delete_elem")
int on_delete(__u64 *ctx)
{
      int k = 0;

      if ((void *)ctx[0] == (void *)&m)
              bpf_map_delete_elem(&m, &k);
      return 0;
}

Without the check it would keep going until the stack overflows

Mike