From: David Vernet <void@manifault.com>
To: Eduard Zingerman <eddyz87@gmail.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, andrii@kernel.org,
daniel@iogearbox.net, martin.lau@linux.dev, kernel-team@fb.com,
yonghong.song@linux.dev
Subject: Re: [PATCH bpf-next v1 1/8] libbpf: allow version suffixes (___smth) for struct_ops types
Date: Wed, 28 Feb 2024 10:29:36 -0600 [thread overview]
Message-ID: <20240228162936.GA148327@maniforge> (raw)
In-Reply-To: <20240227204556.17524-2-eddyz87@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3442 bytes --]
On Tue, Feb 27, 2024 at 10:45:49PM +0200, Eduard Zingerman wrote:
> E.g. allow the following struct_ops definitions:
>
> struct bpf_testmod_ops___v1 { int (*test)(void); };
> struct bpf_testmod_ops___v2 { int (*test)(void); };
>
> SEC(".struct_ops.link")
> struct bpf_testmod_ops___v1 a = { .test = ... }
> SEC(".struct_ops.link")
> struct bpf_testmod_ops___v2 b = { .test = ... }
>
> Where both bpf_testmod_ops__v1 and bpf_testmod_ops__v2 would be
> resolved as 'struct bpf_testmod_ops' from kernel BTF.
>
> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Acked-by: David Vernet <void@manifault.com>
Modulo the leak pointed out by Kui-Feng in another thread. It would be nice if
we could just do this on the stack, but I guess there's no static max size for
a tname.
> ---
> tools/lib/bpf/libbpf.c | 22 +++++++++++++++++-----
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 01f407591a92..abe663927013 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -948,7 +948,7 @@ static int find_btf_by_prefix_kind(const struct btf *btf, const char *prefix,
> const char *name, __u32 kind);
>
> static int
> -find_struct_ops_kern_types(struct bpf_object *obj, const char *tname,
> +find_struct_ops_kern_types(struct bpf_object *obj, const char *tname_raw,
> struct module_btf **mod_btf,
> const struct btf_type **type, __u32 *type_id,
> const struct btf_type **vtype, __u32 *vtype_id,
> @@ -957,15 +957,21 @@ find_struct_ops_kern_types(struct bpf_object *obj, const char *tname,
> const struct btf_type *kern_type, *kern_vtype;
> const struct btf_member *kern_data_member;
> struct btf *btf;
> - __s32 kern_vtype_id, kern_type_id;
> + __s32 kern_vtype_id, kern_type_id, err;
> + char *tname;
> __u32 i;
>
> + tname = strndup(tname_raw, bpf_core_essential_name_len(tname_raw));
> + if (!tname)
> + return -ENOMEM;
> +
> kern_type_id = find_ksym_btf_id(obj, tname, BTF_KIND_STRUCT,
> &btf, mod_btf);
> if (kern_type_id < 0) {
> pr_warn("struct_ops init_kern: struct %s is not found in kernel BTF\n",
> tname);
> - return kern_type_id;
> + err = kern_type_id;
> + goto err_out;
> }
> kern_type = btf__type_by_id(btf, kern_type_id);
>
> @@ -979,7 +985,8 @@ find_struct_ops_kern_types(struct bpf_object *obj, const char *tname,
> if (kern_vtype_id < 0) {
> pr_warn("struct_ops init_kern: struct %s%s is not found in kernel BTF\n",
> STRUCT_OPS_VALUE_PREFIX, tname);
> - return kern_vtype_id;
> + err = kern_vtype_id;
> + goto err_out;
> }
> kern_vtype = btf__type_by_id(btf, kern_vtype_id);
>
> @@ -997,7 +1004,8 @@ find_struct_ops_kern_types(struct bpf_object *obj, const char *tname,
> if (i == btf_vlen(kern_vtype)) {
> pr_warn("struct_ops init_kern: struct %s data is not found in struct %s%s\n",
> tname, STRUCT_OPS_VALUE_PREFIX, tname);
> - return -EINVAL;
> + err = -EINVAL;
> + goto err_out;
> }
>
> *type = kern_type;
> @@ -1007,6 +1015,10 @@ find_struct_ops_kern_types(struct bpf_object *obj, const char *tname,
> *data_member = kern_data_member;
>
> return 0;
> +
> +err_out:
> + free(tname);
> + return err;
> }
>
> static bool bpf_map__is_struct_ops(const struct bpf_map *map)
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-02-28 16:29 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 20:45 [PATCH bpf-next v1 0/8] libbpf: type suffixes and autocreate flag for struct_ops maps Eduard Zingerman
2024-02-27 20:45 ` [PATCH bpf-next v1 1/8] libbpf: allow version suffixes (___smth) for struct_ops types Eduard Zingerman
2024-02-27 21:47 ` Kui-Feng Lee
2024-02-27 21:49 ` Eduard Zingerman
2024-02-28 16:29 ` David Vernet [this message]
2024-02-28 17:28 ` Eduard Zingerman
2024-02-28 17:30 ` David Vernet
2024-02-28 23:21 ` Andrii Nakryiko
2024-02-28 23:37 ` Eduard Zingerman
2024-02-27 20:45 ` [PATCH bpf-next v1 2/8] libbpf: tie struct_ops programs to kernel BTF ids, not to local ids Eduard Zingerman
2024-02-28 7:41 ` Martin KaFai Lau
2024-02-28 17:23 ` David Vernet
2024-02-28 17:40 ` Eduard Zingerman
2024-02-28 17:50 ` David Vernet
2024-02-28 23:28 ` Andrii Nakryiko
2024-02-28 23:31 ` Eduard Zingerman
2024-02-28 23:34 ` Andrii Nakryiko
2024-02-27 20:45 ` [PATCH bpf-next v1 3/8] libbpf: honor autocreate flag for struct_ops maps Eduard Zingerman
2024-02-28 17:44 ` David Vernet
2024-02-27 20:45 ` [PATCH bpf-next v1 4/8] selftests/bpf: test struct_ops map definition with type suffix Eduard Zingerman
2024-02-28 18:03 ` David Vernet
2024-02-27 20:45 ` [PATCH bpf-next v1 5/8] selftests/bpf: bad_struct_ops test Eduard Zingerman
2024-02-28 18:15 ` David Vernet
2024-02-28 20:06 ` Eduard Zingerman
2024-02-28 20:11 ` David Vernet
2024-02-28 23:40 ` Andrii Nakryiko
2024-02-28 23:44 ` Eduard Zingerman
2024-02-28 23:56 ` Andrii Nakryiko
2024-02-29 0:06 ` Eduard Zingerman
2024-02-27 20:45 ` [PATCH bpf-next v1 6/8] selftests/bpf: test autocreate behavior for struct_ops maps Eduard Zingerman
2024-02-28 18:29 ` David Vernet
2024-02-28 18:34 ` David Vernet
2024-02-28 19:31 ` Eduard Zingerman
2024-02-28 23:43 ` Andrii Nakryiko
2024-02-28 23:55 ` Eduard Zingerman
2024-02-29 0:02 ` Andrii Nakryiko
2024-02-29 0:56 ` Martin KaFai Lau
2024-03-01 1:28 ` Eduard Zingerman
2024-03-01 18:03 ` Andrii Nakryiko
2024-03-01 18:07 ` Eduard Zingerman
2024-02-27 20:45 ` [PATCH bpf-next v1 7/8] libbpf: sync progs autoload with maps autocreate " Eduard Zingerman
2024-02-27 22:55 ` Kui-Feng Lee
2024-02-27 23:09 ` Eduard Zingerman
2024-02-27 23:16 ` Kui-Feng Lee
2024-02-27 23:30 ` Eduard Zingerman
2024-02-27 23:40 ` Kui-Feng Lee
2024-02-27 23:43 ` Eduard Zingerman
2024-02-28 0:12 ` Kui-Feng Lee
2024-02-28 0:50 ` Eduard Zingerman
2024-02-28 2:10 ` Martin KaFai Lau
2024-02-28 12:36 ` Eduard Zingerman
2024-02-28 23:55 ` Andrii Nakryiko
2024-02-29 0:04 ` Eduard Zingerman
2024-02-29 0:14 ` Andrii Nakryiko
2024-02-29 0:25 ` Martin KaFai Lau
2024-02-29 0:30 ` Andrii Nakryiko
2024-02-29 0:37 ` Martin KaFai Lau
2024-02-29 0:40 ` Eduard Zingerman
2024-02-27 20:45 ` [PATCH bpf-next v1 8/8] selftests/bpf: tests for struct_ops autoload/autocreate toggling Eduard Zingerman
2024-02-28 18:36 ` David Vernet
2024-02-28 20:10 ` Eduard Zingerman
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=20240228162936.GA148327@maniforge \
--to=void@manifault.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@fb.com \
--cc=martin.lau@linux.dev \
--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.