bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andriin@fb.com>
To: <bpf@vger.kernel.org>, <netdev@vger.kernel.org>, <ast@fb.com>,
	<daniel@iogearbox.net>
Cc: <andrii.nakryiko@gmail.com>, <kernel-team@fb.com>,
	Andrii Nakryiko <andriin@fb.com>
Subject: [PATCH v4 bpf-next 10/17] libbpf: postpone BTF ID finding for TRACING programs to load phase
Date: Fri, 13 Dec 2019 17:43:34 -0800	[thread overview]
Message-ID: <20191214014341.3442258-11-andriin@fb.com> (raw)
In-Reply-To: <20191214014341.3442258-1-andriin@fb.com>

Move BTF ID determination for BPF_PROG_TYPE_TRACING programs to a load phase.
Performing it at open step is inconvenient, because it prevents BPF skeleton
generation on older host kernel, which doesn't contain BTF_KIND_FUNCs
information in vmlinux BTF. This is a common set up, though, when, e.g.,
selftests are compiled on older host kernel, but the test program itself is
executed in qemu VM with bleeding edge kernel. Having this BTF searching
performed at load time allows to successfully use bpf_object__open() for
codegen and inspection of BPF object file.

Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
---
 tools/lib/bpf/libbpf.c | 37 ++++++++++++++++++-------------------
 1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 06dfa36ed0bb..3488ac4f7015 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -3815,11 +3815,22 @@ load_program(struct bpf_program *prog, struct bpf_insn *insns, int insns_cnt,
 	return ret;
 }
 
-int
-bpf_program__load(struct bpf_program *prog,
-		  char *license, __u32 kern_version)
+static int libbpf_find_attach_btf_id(const char *name,
+				     enum bpf_attach_type attach_type,
+				     __u32 attach_prog_fd);
+
+int bpf_program__load(struct bpf_program *prog, char *license, __u32 kern_ver)
 {
-	int err = 0, fd, i;
+	int err = 0, fd, i, btf_id;
+
+	if (prog->type == BPF_PROG_TYPE_TRACING) {
+		btf_id = libbpf_find_attach_btf_id(prog->section_name,
+						   prog->expected_attach_type,
+						   prog->attach_prog_fd);
+		if (btf_id <= 0)
+			return btf_id;
+		prog->attach_btf_id = btf_id;
+	}
 
 	if (prog->instances.nr < 0 || !prog->instances.fds) {
 		if (prog->preprocessor) {
@@ -3843,7 +3854,7 @@ bpf_program__load(struct bpf_program *prog,
 				prog->section_name, prog->instances.nr);
 		}
 		err = load_program(prog, prog->insns, prog->insns_cnt,
-				   license, kern_version, &fd);
+				   license, kern_ver, &fd);
 		if (!err)
 			prog->instances.fds[0] = fd;
 		goto out;
@@ -3872,9 +3883,7 @@ bpf_program__load(struct bpf_program *prog,
 		}
 
 		err = load_program(prog, result.new_insn_ptr,
-				   result.new_insn_cnt,
-				   license, kern_version, &fd);
-
+				   result.new_insn_cnt, license, kern_ver, &fd);
 		if (err) {
 			pr_warn("Loading the %dth instance of program '%s' failed\n",
 				i, prog->section_name);
@@ -3918,9 +3927,6 @@ bpf_object__load_progs(struct bpf_object *obj, int log_level)
 	return 0;
 }
 
-static int libbpf_find_attach_btf_id(const char *name,
-				     enum bpf_attach_type attach_type,
-				     __u32 attach_prog_fd);
 static struct bpf_object *
 __bpf_object__open(const char *path, const void *obj_buf, size_t obj_buf_sz,
 		   const struct bpf_object_open_opts *opts)
@@ -3984,15 +3990,8 @@ __bpf_object__open(const char *path, const void *obj_buf, size_t obj_buf_sz,
 
 		bpf_program__set_type(prog, prog_type);
 		bpf_program__set_expected_attach_type(prog, attach_type);
-		if (prog_type == BPF_PROG_TYPE_TRACING) {
-			err = libbpf_find_attach_btf_id(prog->section_name,
-							attach_type,
-							attach_prog_fd);
-			if (err <= 0)
-				goto out;
-			prog->attach_btf_id = err;
+		if (prog_type == BPF_PROG_TYPE_TRACING)
 			prog->attach_prog_fd = attach_prog_fd;
-		}
 	}
 
 	return obj;
-- 
2.17.1


  parent reply	other threads:[~2019-12-14  1:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-14  1:43 [PATCH v4 bpf-next 00/17] Add code-generated BPF object skeleton support Andrii Nakryiko
2019-12-14  1:43 ` [PATCH v4 bpf-next 01/17] libbpf: don't require root for bpf_object__open() Andrii Nakryiko
2019-12-14  1:43 ` [PATCH v4 bpf-next 02/17] libbpf: add generic bpf_program__attach() Andrii Nakryiko
2019-12-14  1:43 ` [PATCH v4 bpf-next 03/17] libbpf: move non-public APIs from libbpf.h to libbpf_internal.h Andrii Nakryiko
2019-12-14  1:43 ` [PATCH v4 bpf-next 04/17] libbpf: add BPF_EMBED_OBJ macro for embedding BPF .o files Andrii Nakryiko
2019-12-14  1:43 ` [PATCH v4 bpf-next 05/17] libbpf: extract common user-facing helpers Andrii Nakryiko
2019-12-14  1:43 ` [PATCH v4 bpf-next 06/17] libbpf: expose btf__align_of() API Andrii Nakryiko
2019-12-14  1:43 ` [PATCH v4 bpf-next 07/17] libbpf: expose BTF-to-C type declaration emitting API Andrii Nakryiko
2019-12-14  1:43 ` [PATCH v4 bpf-next 08/17] libbpf: expose BPF program's function name Andrii Nakryiko
2019-12-14  1:43 ` [PATCH v4 bpf-next 09/17] libbpf: refactor global data map initialization Andrii Nakryiko
2019-12-14  1:43 ` Andrii Nakryiko [this message]
2019-12-14  1:43 ` [PATCH v4 bpf-next 11/17] libbpf: reduce log level of supported section names dump Andrii Nakryiko
2019-12-14  1:43 ` [PATCH v4 bpf-next 12/17] libbpf: add BPF object skeleton support Andrii Nakryiko
2019-12-14  1:43 ` [PATCH v4 bpf-next 13/17] bpftool: add skeleton codegen command Andrii Nakryiko
2019-12-14  1:43 ` [PATCH v4 bpf-next 14/17] selftests/bpf: add BPF skeletons selftests and convert attach_probe.c Andrii Nakryiko
2019-12-14  1:43 ` [PATCH v4 bpf-next 15/17] selftests/bpf: convert few more selftest to skeletons Andrii Nakryiko
2019-12-14  1:43 ` [PATCH v4 bpf-next 16/17] selftests/bpf: add test validating data section to struct convertion layout Andrii Nakryiko
2019-12-14  1:43 ` [PATCH v4 bpf-next 17/17] bpftool: add `gen skeleton` BASH completions Andrii Nakryiko
2019-12-16  0:30 ` [PATCH v4 bpf-next 00/17] Add code-generated BPF object skeleton support Alexei Starovoitov
2019-12-16  2:01   ` Andrii Nakryiko
2019-12-16  4:45     ` Alexei Starovoitov
2019-12-16 19:35       ` Andrii Nakryiko

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=20191214014341.3442258-11-andriin@fb.com \
    --to=andriin@fb.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    /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).