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

["JP Kobryn (CrowdStrike)" <jp.kobryn@linux.dev>]

On 11/10/26 12:43 PM, Mike Bazov wrote:
> On Mon, Nov 9, 2026 at 4:12 PM JP Kobryn wrote:
>> Before moving away from an in-kernel solution, can we consider the
>> direction this patch below takes?
> 
> I haven't proposed moving away from an in-kernel solution. Your patch
> is the same design I proposed earlier in this thread ("This is what I
> have in mind for v2") with Andrii's bpf_ctx suggestion folded in, and
> it's what I've been putting together for v2 (unless someone comes up
> with a better direction), which is nearly ready to
> post, so let's avoid duplicating the work.

Perhaps I could've replied inline to the mention of reusing bpf_ctx. I
read it as assuming the chain was already traversable. After
experimenting with making nesting traversable through the common
bpf_run_ctx, I shared the RFC to help validate that direction.

> 
> beyond trampoline progs, v2 also covers raw_tp, tp_btf, syscall
> tracepoints, and BPF_PROG_TEST_RUN, and disables the per-CPU private
> stack for preemptible tracing progs since two tasks can now run the
> same prog concurrently on one CPU.
> 
> a couple of notes on your patch:
> 
> - Passing prog to bpf_set_run_ctx() churns all callers that don't do
>   recursion checks, and doesn't fit bpf_prog_run_array_sleepable(),
>   which reuses one bpf_run_ctx across all progs in the array. In v2,
>   bpf_set_run_ctx() keeps its signature and initializes prog to NULL,
>   and bpf_prog_enter_recur_ctx() sets it after the walk succeeds.
> - bpf_io_uring_submit_sqes() calls bpf_set_run_ctx(NULL), so
>   dereferencing new_ctx unconditionally will NULL-deref there.
> - Cross-task synchronization isn't needed: a task only ever walks its
>   own current->bpf_ctx chain (and any IRQ/NMI on top of it runs on the
>   same CPU and walks the same chain), so compiler barriers around
>   linking and unlinking the frame are sufficient.

Fair points on 1 & 2. On 3, "cross-task" was originally inaccurate
wording. The intention was cross-context visibility under
interrupts.

> 
> I'll Cc you on v2 once I post it (probably by tomorrow evening UTC).
> testing and review there would be appreciated.

Sounds good.