Re: [PATCH bpf v3 1/2] bpf: disable private stack for sleepable programs

[Jiri Olsa <olsajiri@gmail.com>]

On Thu, Aug 27, 2026 at 09:55:08AM -0700, Alexei Starovoitov wrote:
> On Thu, Aug 27, 2026 at 9:40 AM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Thu, Aug 27, 2026 at 9:35 AM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > On Thu, Aug 27, 2026 at 7:56 AM Andrii Nakryiko
> > > <andrii.nakryiko@gmail.com> wrote:
> > > >
> > > > On Tue, Aug 25, 2026 at 6:20 PM Alexei Starovoitov
> > > > <alexei.starovoitov@gmail.com> wrote:
> > > > >
> > > > > On Sat Aug 22, 2026 at 3:54 PM PDT, Christian Simon wrote:
> > > > > > A JITed BPF program can use one private stack per program and CPU.
> > > > > > Sleepable programs can be preempted, allowing another task to run the
> > > > > > same program on the same CPU. The second invocation then reuses and can
> > > > > > overwrite the first invocation's private stack.
> > > > >
> > > > > I'm confused by this. sleepable progs go through __bpf_prog_enter_sleepable_recur()
> > > > > which has per-prog recurison counter. So preemption of the prog
> > > > > doesn't break private stack.
> > > > > If the same prog attemps to execute on the same cpu it will be skipped.
> > > > >
> > > > > syscall prog types go via bpf_prog_run_array_sleepable()
> > > > > that have per prog recursions counter.
> > > > >
> > > > > Looks like we're not doing it for bpf_prog_run_array_uprobe().
> > > > > I'm not sure what the right trade off here.
> > > > > I feel universally checking for recursion is better
> > > > > then selectively disabling private stack for uprobe.
> > > >
> > > > I'd really like to avoid adding this "recursion protection" to uprobe.
> > > > With uprobes, there is no recursion, it's called from well defined
> > > > context in the kernel and you can't have recursive uprobe BPF
> > > > programs.
> > > >
> > > > All you can have is a very valid and possible sleepable uprobe
> > > > interleaving, which the user cannot prevent or work around, they have
> > > > no control over this and it's just a fact of life.
> > > >
> > > >  E.g., a simple scenario, we attach one bpf program (let's call it U)
> > > > to some USDT. BPF program U is sleepable and actually can sleep due to
> > > > page faults (e.g., unwinding Python stack trace requires sleepable
> > > > mode for reliably getting filename strings from Python runtime, which
> > > > are not always paged in).
> > > >
> > > > In such a case, you can have thread A and thread B both hitting the
> > > > same USDT (e.g., somewhere in memory allocator or whatnot). Let's say
> > > > thread A hits it first on CPU X, BPF program U starts executing and
> > > > unwinding Python stack, does bpf_copy_from_user() for string contents
> > > > and causes page fault, is taken off CPU X. Meanwhile thread B hits
> > > > USDT on the same CPU X, kernel runs program U, and it is supposed to
> > > > work completely independently and concurrently (no shared state or
> > > > whatever) from U's execution in thread A.
> > > >
> > > > Yet, if we add this per-CPU "recursion check", we'll just skip U's
> > > > execution for thread B. This is data loss, and it's very bad in
> > > > practice because it frequently just invalidates the entire data
> > > > collection trustworthiness.
> > >
> > > ok. fair
> > >
> >
> > great, thanks!
> >
> > > > So I think we should disable private stack for uprobes (sleepable or
> > > > not) instead. I'm not sure private stack buys us anything for uprobe
> > > > cases.
> > >
> > > why disable priv stack for non-sleepable uprobes?
> > > While non-sleepable bpf prog is executing the same or different
> > > uprobe cannot execute on the same cpu.
> > > So bpf prog can be preempted by kernel execution,
> > > but a user task cannot start preempt bpf prog,
> > > so 2nd uprobe cannot start running,
> > > no?
> >
> > I think that changes on preemptible kernels, this was called out in
> > discussions on previous versions of this patch. So only for that
> > reason.
> 
> my understanding is that preemptable kernel doesn't mean that
> bpf prog can be preempted by user space.
> only by kernel.
> 
> I looked up earlier thread, but don't understand what Jiri meant.
> 
> Jiri,
> please clarify what problem do you see with non-sleepable uprobes?

hum.. non-sleepable uprobe prog is run by bpf_prog_run_array_uprobe
and it disables only task migration, preemption is not disabled and
holds rcu_read_lock (which seems ok for preemption)

so I'm not sure why it wouldn't be preemptible by another task

jirka