From: Jiri Olsa <olsajiri@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Christian Simon <simon@swine.de>,
bpf@vger.kernel.org, ast@kernel.org, andrii@kernel.org,
daniel@iogearbox.net, martin.lau@kernel.org, tj@kernel.org,
yonghong.song@linux.dev, stable@vger.kernel.org,
andrii.nakryiko@gmail.com, olsajiri@gmail.com
Subject: Re: [PATCH bpf v3 1/2] bpf: disable private stack for sleepable programs
Date: Wed, 26 Aug 2026 15:11:46 +0200 [thread overview]
Message-ID: <ao7mEnrgVNj7prrI@krava> (raw)
In-Reply-To: <DKYHBHNAMR03.B8SKDLC9FQ94@gmail.com>
On Tue, Aug 25, 2026 at 06:20:16PM -0700, Alexei Starovoitov 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.
also during the load we can't tell if kprobe program will be attached
as kprobe or uprobe [1] so having a way to disable private stack for
a program would solve this as well
jirka
[1] https://lore.kernel.org/bpf/ao2f-rBgT0SqX6Pw@krava/
>
> > Disable private stack for sleepable programs so they use the regular kernel
> > stack, which handles preemption correctly. This change is intentionally
> > limited to programs marked sleepable; preemptible non-sleepable dispatch
> > paths require separate protection.
> >
> > Fixes: 7d1cd70d4b16 ("bpf, x86: Support private stack in jit")
> > Fixes: 6c17a882d380 ("bpf, arm64: JIT support for private stack")
> > Fixes: 156d985123b6 ("powerpc64/bpf: Implement JIT support for private stack")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Christian Simon <simon@swine.de>
> > ---
> > kernel/bpf/verifier.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 5e37ca75e5c4..038753ef07a9 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -5237,6 +5237,15 @@ static enum priv_stack_mode bpf_enable_priv_stack(struct bpf_prog *prog)
> > if (!bpf_jit_supports_private_stack())
> > return NO_PRIV_STACK;
> >
> > + /*
> > + * Sleepable programs can be preempted, allowing another task to run
> > + * the same program on the same CPU. Since private stack is per-CPU
> > + * and per-program, the second invocation would corrupt the first's
> > + * stack. Disable private stack for sleepable programs.
> > + */
> > + if (prog->sleepable)
> > + return NO_PRIV_STACK;
>
> This is not true in genreal. sleepable progs can use priv stack.
>
> pw-bot: cr
next prev parent reply other threads:[~2026-08-26 13:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-22 22:54 [PATCH bpf v3 0/2] disable private stack for sleepable programs Christian Simon
2026-08-22 22:54 ` [PATCH bpf v3 1/2] bpf: " Christian Simon
2026-08-22 23:10 ` sashiko-bot
2026-08-22 23:46 ` bot+bpf-ci
2026-08-26 1:20 ` Alexei Starovoitov
2026-08-26 13:11 ` Jiri Olsa [this message]
2026-08-27 14:56 ` Andrii Nakryiko
2026-08-27 16:35 ` Alexei Starovoitov
2026-08-27 16:40 ` Andrii Nakryiko
2026-08-27 16:55 ` Alexei Starovoitov
2026-08-27 22:32 ` Jiri Olsa
2026-08-22 22:54 ` [PATCH bpf v3 2/2] selftests/bpf: verify preemptible uprobes avoid private stack Christian Simon
2026-08-22 23:05 ` sashiko-bot
2026-08-22 23:58 ` bot+bpf-ci
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ao7mEnrgVNj7prrI@krava \
--to=olsajiri@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=martin.lau@kernel.org \
--cc=simon@swine.de \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.