bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
To: bpf@vger.kernel.org
Cc: Eduard Zingerman <eddyz87@gmail.com>,
	Emil Tsalapatis <emil@etsalapatis.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <martin.lau@kernel.org>,
	Barret Rhoden <brho@google.com>,
	Matt Bobrowski <mattbobrowski@google.com>,
	kkd@meta.com, kernel-team@meta.com
Subject: [PATCH bpf-next v5 05/12] bpf: Add function to find program from stack trace
Date: Thu,  3 Jul 2025 13:48:11 -0700	[thread overview]
Message-ID: <20250703204818.925464-6-memxor@gmail.com> (raw)
In-Reply-To: <20250703204818.925464-1-memxor@gmail.com>

In preparation of figuring out the closest program that led to the
current point in the kernel, implement a function that scans through the
stack trace and finds out the closest BPF program when walking down the
stack trace.

Special care needs to be taken to skip over kernel and BPF subprog
frames. We basically scan until we find a BPF main prog frame. The
assumption is that if a program calls into us transitively, we'll
hit it along the way. If not, we end up returning NULL.

Contextually the function will be used in places where we know the
program may have called into us.

Due to reliance on arch_bpf_stack_walk(), this function only works on
x86 with CONFIG_UNWINDER_ORC, arm64, and s390. Remove the warning from
arch_bpf_stack_walk as well since we call it outside bpf_throw()
context.

Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
---
 arch/x86/net/bpf_jit_comp.c |  1 -
 include/linux/bpf.h         |  1 +
 kernel/bpf/core.c           | 33 +++++++++++++++++++++++++++++++++
 3 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 15672cb926fc..40e1b3b9634f 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -3845,7 +3845,6 @@ void arch_bpf_stack_walk(bool (*consume_fn)(void *cookie, u64 ip, u64 sp, u64 bp
 	}
 	return;
 #endif
-	WARN(1, "verification of programs using bpf_throw should have failed\n");
 }
 
 void bpf_arch_poke_desc_update(struct bpf_jit_poke_descriptor *poke,
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 09f06b1ea62e..4d577352f3e6 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -3662,5 +3662,6 @@ static inline bool bpf_is_subprog(const struct bpf_prog *prog)
 
 int bpf_prog_get_file_line(struct bpf_prog *prog, unsigned long ip, const char **filep,
 			   const char **linep, int *nump);
+struct bpf_prog *bpf_prog_find_from_stack(void);
 
 #endif /* _LINUX_BPF_H */
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 833442661742..037d67cf5fb1 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -3262,4 +3262,37 @@ int bpf_prog_get_file_line(struct bpf_prog *prog, unsigned long ip, const char *
 	return 0;
 }
 
+struct walk_stack_ctx {
+	struct bpf_prog *prog;
+};
+
+static bool find_from_stack_cb(void *cookie, u64 ip, u64 sp, u64 bp)
+{
+	struct walk_stack_ctx *ctxp = cookie;
+	struct bpf_prog *prog;
+
+	/*
+	 * The RCU read lock is held to safely traverse the latch tree, but we
+	 * don't need its protection when accessing the prog, since it has an
+	 * active stack frame on the current stack trace, and won't disappear.
+	 */
+	rcu_read_lock();
+	prog = bpf_prog_ksym_find(ip);
+	rcu_read_unlock();
+	if (!prog)
+		return true;
+	if (bpf_is_subprog(prog))
+		return true;
+	ctxp->prog = prog;
+	return false;
+}
+
+struct bpf_prog *bpf_prog_find_from_stack(void)
+{
+	struct walk_stack_ctx ctx = {};
+
+	arch_bpf_stack_walk(find_from_stack_cb, &ctx);
+	return ctx.prog;
+}
+
 #endif
-- 
2.47.1


  parent reply	other threads:[~2025-07-03 20:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-03 20:48 [PATCH bpf-next v5 00/12] BPF Standard Streams Kumar Kartikeya Dwivedi
2025-07-03 20:48 ` [PATCH bpf-next v5 01/12] bpf: Refactor bprintf buffer support Kumar Kartikeya Dwivedi
2025-07-03 20:48 ` [PATCH bpf-next v5 02/12] bpf: Introduce BPF standard streams Kumar Kartikeya Dwivedi
2025-07-03 20:48 ` [PATCH bpf-next v5 03/12] bpf: Add function to extract program source info Kumar Kartikeya Dwivedi
2025-07-03 20:48 ` [PATCH bpf-next v5 04/12] bpf: Ensure RCU lock is held around bpf_prog_ksym_find Kumar Kartikeya Dwivedi
2025-07-03 20:48 ` Kumar Kartikeya Dwivedi [this message]
2025-07-03 20:48 ` [PATCH bpf-next v5 06/12] bpf: Add dump_stack() analogue to print to BPF stderr Kumar Kartikeya Dwivedi
2025-07-03 20:48 ` [PATCH bpf-next v5 07/12] bpf: Report may_goto timeout " Kumar Kartikeya Dwivedi
2025-07-03 20:48 ` [PATCH bpf-next v5 08/12] bpf: Report rqspinlock deadlocks/timeout " Kumar Kartikeya Dwivedi
2025-07-30 23:02   ` Kees Cook
2025-07-30 23:07     ` Alexei Starovoitov
2025-07-30 23:09       ` Kees Cook
2025-07-30 23:13         ` Alexei Starovoitov
2025-07-30 23:19           ` Kees Cook
2025-07-03 20:48 ` [PATCH bpf-next v5 09/12] libbpf: Add bpf_stream_printk() macro Kumar Kartikeya Dwivedi
2025-07-03 20:48 ` [PATCH bpf-next v5 10/12] libbpf: Introduce bpf_prog_stream_read() API Kumar Kartikeya Dwivedi
2025-07-03 20:48 ` [PATCH bpf-next v5 11/12] bpftool: Add support for dumping streams Kumar Kartikeya Dwivedi
2025-07-03 20:48 ` [PATCH bpf-next v5 12/12] selftests/bpf: Add tests for prog streams Kumar Kartikeya Dwivedi
2025-07-04  2:40 ` [PATCH bpf-next v5 00/12] BPF Standard Streams 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=20250703204818.925464-6-memxor@gmail.com \
    --to=memxor@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brho@google.com \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=kernel-team@meta.com \
    --cc=kkd@meta.com \
    --cc=martin.lau@kernel.org \
    --cc=mattbobrowski@google.com \
    /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;
as well as URLs for NNTP newsgroup(s).