From: Feng Yang <yangfeng59949@163.com>
To: bot+bpf-ci@kernel.org
Cc: andrii@kernel.org, ast@kernel.org, bpf@vger.kernel.org,
daniel@iogearbox.net, eddyz87@gmail.com, emil@etsalapatis.com,
ihor.solodrai@linux.dev, jolsa@kernel.org, kpsingh@kernel.org,
linux-kselftest@vger.kernel.org,
linux-trace-kernel@vger.kernel.org, martin.lau@kernel.org,
martin.lau@linux.dev, mason@kernel.org,
mathieu.desnoyers@efficios.com, matt@bobrowski.net,
memxor@gmail.com, mhiramat@kernel.org, rostedt@goodmis.org,
song@kernel.org, yangfeng59949@163.com, yonghong.song@linux.dev
Subject: Re: [PATCH bpf-next v5 1/2] bpf: Add sleepable version of bpf_get_stack in raw_tp_prog_func_proto and tp_prog_func_proto
Date: Fri, 13 Nov 2026 14:56:54 +0800 [thread overview]
Message-ID: <20261113065654.523979-1-yangfeng59949@163.com> (raw)
In-Reply-To: <b7b3f0926c35e8192180326438de9b6c119125a50ffb23b8d5754f31f47a999c@mail.kernel.org>
On Fri, 6 Nov 2026 08:50:02 +0000 bot+bpf-ci@kernel.org wroted:
[ ... ]
> > @@ -1725,7 +1774,8 @@ raw_tp_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> > case BPF_FUNC_get_stackid:
> > return &bpf_get_stackid_proto_raw_tp;
> > case BPF_FUNC_get_stack:
> > - return &bpf_get_stack_proto_raw_tp;
> > + return prog->sleepable ? &bpf_get_stack_proto_raw_tp_sleepable
> > + : &bpf_get_stack_proto_raw_tp;
> > case BPF_FUNC_get_attach_cookie:
> > return &bpf_get_attach_cookie_proto_tracing;
> > default:
>
> Can this make sleepable programs that load today fail to load?
>
> The new prototypes set .might_sleep = true, and check_helper_call() rejects
> such a helper whenever in_sleepable_context() is false:
>
> if (fn->might_sleep && !in_sleepable_context(env)) {
> verbose(env, "sleepable helper %s#%d in %s\n", ...);
> ...
> return -EINVAL;
> }
>
> in_sleepable_context() is false inside bpf_rcu_read_lock(),
> bpf_preempt_disable(), bpf_local_irq_save() and lock regions, and inside
> rcu callbacks such as bpf_for_each_map_elem() on hash maps and
> bpf_find_vma().
>
> Before this patch the same call resolved to bpf_get_stack_proto_raw_tp or
> bpf_get_stack_proto_tp, which do not set might_sleep and never fault. For
> example:
>
> SEC("lsm.s/file_open")
> int prog(void *ctx) {
> bpf_rcu_read_lock();
> bpf_get_stack(ctx, buf, sizeof(buf), 0);
> bpf_rcu_read_unlock();
> return 0;
> }
This patch is effectively d4dd9775ec24 + 9d02927fdf4e applied to the remaining
program types in one step: the resulting behavior matches uprobe.
If the rejection is acceptable for uprobe, we would prefer to keep the new types consistent with it.
> loads today and would be rejected with "sleepable helper bpf_get_stack#67 in
> rcu_read_lock region".
>
> The call chain is bpf_lsm_func_proto() -> tracing_prog_func_proto() ->
> raw_tp_prog_func_proto(). The same applies to sleepable raw_tp,
> tracepoint, fentry/fexit/fmod_ret, fsession and iter programs. It also
> applies to every BPF_PROG_TYPE_SYSCALL program, since check_attach_btf_id()
> forces those to be sleepable.
>
> The rejection happens even when BPF_F_USER_BUILD_ID is not passed, so the
> helper could not sleep in those calls.
>
> The commit message acknowledges this ("such programs load today") and cites
> commit 9d02927fdf4e as precedent. That commit fixed prototypes that could
> actually sleep in non-sleepable regions, whereas here the old prototypes
> were correct.
>
> The verifier already records per-insn non-sleepable call sites in
> env->insn_aux_data[insn_idx].non_sleepable, and specialize_kfunc() uses
> that to pick bpf_arena_alloc_pages_non_sleepable(). Could the non-faulting
> implementation be selected the same way at fixup time for call sites that
> are not always sleepable, instead of rejecting them?
If we do need to keep the existing unaffected behavior, would this change be similar to
the operation below?
diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
index 1d33a78d9373..d91211b15770 100644
--- a/kernel/bpf/fixups.c
+++ b/kernel/bpf/fixups.c
@@ -3416,6 +3416,9 @@ int bpf_do_misc_fixups(struct bpf_verifier_env *env)
func_id_name(insn->imm), insn->imm);
return -EFAULT;
}
+ if (fn->might_sleep && env->insn_aux_data[i].non_sleepable &&
+ insn->imm == BPF_FUNC_get_stack)
+ fn = bpf_get_stack_proto_nosleep(env->prog);
insn->imm = BPF_CALL_IMM(fn->func);
next_insn:
if (subprogs[cur_subprog + 1].start == i + 1) {
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index bb1659ce7a5c..f73dd67f523e 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -13107,6 +13107,10 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
return err;
}
+ if (fn->might_sleep && !in_sleepable_context(env) &&
+ func_id == BPF_FUNC_get_stack)
+ fn = bpf_get_stack_proto_nosleep(env->prog);
+
/* eBPF programs must be GPL compatible to use GPL-ed functions */
if (!env->prog->gpl_compatible && fn->gpl_only) {
verbose(env, "cannot call GPL-restricted function from non-GPL compatible program\n");
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 1229ee06dd71..9eed63059449 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -1765,6 +1765,22 @@ static const struct bpf_func_proto bpf_get_stack_proto_raw_tp_sleepable = {
.arg4_type = ARG_ANYTHING,
};
+const struct bpf_func_proto *
+bpf_get_stack_proto_nosleep(const struct bpf_prog *prog)
+{
+ switch (resolve_prog_type(prog)) {
+ case BPF_PROG_TYPE_TRACEPOINT:
+ return &bpf_get_stack_proto_tp;
+ case BPF_PROG_TYPE_RAW_TRACEPOINT:
+ case BPF_PROG_TYPE_TRACING:
+ case BPF_PROG_TYPE_LSM:
+ case BPF_PROG_TYPE_SYSCALL:
+ return &bpf_get_stack_proto_raw_tp;
+ default:
+ return &bpf_get_stack_proto;
+ }
+}
next prev parent reply other threads:[~2026-11-13 6:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 8:07 [PATCH bpf-next v5 1/2] bpf: Add sleepable version of bpf_get_stack in raw_tp_prog_func_proto and tp_prog_func_proto Feng Yang
2026-11-06 8:07 ` [PATCH bpf-next v5 2/2] selftests/bpf: Test faulting build IDs from a sleepable raw tracepoint Feng Yang
2026-11-06 8:50 ` [PATCH bpf-next v5 1/2] bpf: Add sleepable version of bpf_get_stack in raw_tp_prog_func_proto and tp_prog_func_proto bot+bpf-ci
2026-11-13 6:56 ` Feng Yang [this message]
2026-11-13 21:32 ` Andrii Nakryiko
2026-11-13 22:00 ` patchwork-bot+netdevbpf
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=20261113065654.523979-1-yangfeng59949@163.com \
--to=yangfeng59949@163.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=mason@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=matt@bobrowski.net \
--cc=memxor@gmail.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=song@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox