From: Martin KaFai Lau <martin.lau@linux.dev>
To: "D. Wythe" <alibuda@linux.alibaba.com>
Cc: kgraul@linux.ibm.com, wenjia@linux.ibm.com, jaka@linux.ibm.com,
ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
pabeni@redhat.com, song@kernel.org, sdf@google.com,
haoluo@google.com, yhs@fb.com, edumazet@google.com,
john.fastabend@gmail.com, kpsingh@kernel.org, jolsa@kernel.org,
guwen@linux.alibaba.com, kuba@kernel.org, davem@davemloft.net,
netdev@vger.kernel.org, linux-s390@vger.kernel.org,
linux-rdma@vger.kernel.org, bpf@vger.kernel.org,
Daniel Xu <dlxu@meta.com>
Subject: Re: [PATCH bpf-next v3 4/5] libbpf: fix error when st-prefix_ops and ops from differ btf
Date: Thu, 19 Dec 2024 14:43:30 -0800 [thread overview]
Message-ID: <2f56aca3-a27a-49b6-90de-7f1b2ff39df1@linux.dev> (raw)
In-Reply-To: <20241218024422.23423-5-alibuda@linux.alibaba.com>
On 12/17/24 6:44 PM, D. Wythe wrote:
> When a struct_ops named xxx_ops was registered by a module, and
> it will be used in both built-in modules and the module itself,
> so that the btf_type of xxx_ops will be present in btf_vmlinux
> instead of in btf_mod, which means that the btf_type of
> bpf_struct_ops_xxx_ops and xxx_ops will not be in the same btf.
>
> Here are four possible case:
>
> +--------+-------------+-------------+---------------------------------+
> | | st_opx_xxx | xxx | |
> +--------+-------------+-------------+---------------------------------+
> | case 0 | btf_vmlinux | bft_vmlinux | be used and reg only in vmlinux |
> +--------+-------------+-------------+---------------------------------+
> | case 1 | btf_vmlinux | bpf_mod | INVALID |
> +--------+-------------+-------------+---------------------------------+
> | case 2 | btf_mod | btf_vmlinux | reg in mod but be used both in |
> | | | | vmlinux and mod. |
> +--------+-------------+-------------+---------------------------------+
> | case 3 | btf_mod | btf_mod | be used and reg only in mod |
> +--------+-------------+-------------+---------------------------------+
>
> At present, cases 0, 1, and 3 can be correctly identified, because
> st_ops_xxx is searched from the same btf with xxx. In order to
> handle case 2 correctly without affecting other cases, we cannot simply
> change the search method for st_ops_xxx from find_btf_by_prefix_kind()
> to find_ksym_btf_id(), because in this way, case 1 will not be
> recognized anymore.
>
> To address this issue, if st_ops_xxx cannot be found in the btf with xxx
> and mod_btf does not exist, do find_ksym_btf_id() again to
> avoid such issue.
>
> Fixes: 590a00888250 ("bpf: libbpf: Add STRUCT_OPS support")
> Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
> ---
> tools/lib/bpf/libbpf.c | 25 +++++++++++++++++--------
> 1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 66173ddb5a2d..56bf74894110 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -1005,7 +1005,8 @@ find_struct_ops_kern_types(struct bpf_object *obj, const char *tname_raw,
> const struct btf_member *kern_data_member;
> struct btf *btf = NULL;
> __s32 kern_vtype_id, kern_type_id;
> - char tname[256];
> + char tname[256], stname[256];
> + int ret;
> __u32 i;
>
> snprintf(tname, sizeof(tname), "%.*s",
> @@ -1020,17 +1021,25 @@ find_struct_ops_kern_types(struct bpf_object *obj, const char *tname_raw,
> }
> kern_type = btf__type_by_id(btf, kern_type_id);
>
> + ret = snprintf(stname, sizeof(stname), "%s%s", STRUCT_OPS_VALUE_PREFIX, tname);
How about always look for "struct bpf_struct_ops_smc_ops" first, figure out the
btf, and then look for "struct smc_ops", would it work?
If CONFIG_SMC=y instead of =m, this change cannot be tested?
> + if (ret < 0 || ret >= sizeof(stname))
> + return -ENAMETOOLONG;
> +
> /* Find the corresponding "map_value" type that will be used
> * in map_update(BPF_MAP_TYPE_STRUCT_OPS). For example,
> * find "struct bpf_struct_ops_tcp_congestion_ops" from the
> * btf_vmlinux.
> */
> - kern_vtype_id = find_btf_by_prefix_kind(btf, STRUCT_OPS_VALUE_PREFIX,
> - tname, BTF_KIND_STRUCT);
> + kern_vtype_id = btf__find_by_name_kind(btf, stname, BTF_KIND_STRUCT);
> 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;
> + if (kern_vtype_id == -ENOENT && !*mod_btf)
> + kern_vtype_id = find_ksym_btf_id(obj, stname, BTF_KIND_STRUCT,
> + &btf, mod_btf);
> + if (kern_vtype_id < 0) {
> + pr_warn("struct_ops init_kern: struct %s is not found in kernel BTF\n",
> + stname);
> + return kern_vtype_id;
> + }
> }
> kern_vtype = btf__type_by_id(btf, kern_vtype_id);
>
> @@ -1046,8 +1055,8 @@ find_struct_ops_kern_types(struct bpf_object *obj, const char *tname_raw,
> break;
> }
> 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);
> + pr_warn("struct_ops init_kern: struct %s data is not found in struct %s\n",
> + tname, stname);
> return -EINVAL;
> }
>
next prev parent reply other threads:[~2024-12-19 22:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-18 2:44 [PATCH bpf-next v3 0/5] net/smc: Introduce smc_ops D. Wythe
2024-12-18 2:44 ` [PATCH bpf-next v3 1/5] bpf: export necessary sympols for modules with struct_ops D. Wythe
2024-12-18 2:44 ` [PATCH bpf-next v3 2/5] net/smc: Introduce generic hook smc_ops D. Wythe
2024-12-18 2:44 ` [PATCH bpf-next v3 3/5] net/smc: bpf: register smc_ops info struct_ops D. Wythe
2024-12-19 22:48 ` Martin KaFai Lau
2024-12-23 2:00 ` D. Wythe
2024-12-26 19:44 ` Zhu Yanjun
2025-01-03 6:54 ` D. Wythe
2024-12-18 2:44 ` [PATCH bpf-next v3 4/5] libbpf: fix error when st-prefix_ops and ops from differ btf D. Wythe
2024-12-19 22:43 ` Martin KaFai Lau [this message]
2024-12-23 2:10 ` D. Wythe
2025-01-07 23:24 ` Martin KaFai Lau
2025-01-08 13:45 ` D. Wythe
2025-01-10 23:38 ` Andrii Nakryiko
2025-01-14 7:11 ` D. Wythe
2024-12-18 2:44 ` [PATCH bpf-next v3 5/5] bpf/selftests: add selftest for bpf_smc_ops D. Wythe
2024-12-19 22:59 ` Martin KaFai Lau
2024-12-23 2:03 ` D. Wythe
[not found] ` <bf1eef2ada1330c92b6326e90e23482e53a759fd40cd6c25832ae7f72207930a@mail.kernel.org>
[not found] ` <20241218043231.GA9245@j66a10360.sqa.eu95>
[not found] ` <1425b222-b5a5-4f18-a65b-af37226d099e@iogearbox.net>
[not found] ` <20241219040409.GA107394@j66a10360.sqa.eu95>
2024-12-19 5:23 ` [PATCH bpf-next v3 0/5] net/smc: Introduce smc_ops Daniel Xu
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=2f56aca3-a27a-49b6-90de-7f1b2ff39df1@linux.dev \
--to=martin.lau@linux.dev \
--cc=alibuda@linux.alibaba.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dlxu@meta.com \
--cc=edumazet@google.com \
--cc=guwen@linux.alibaba.com \
--cc=haoluo@google.com \
--cc=jaka@linux.ibm.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kgraul@linux.ibm.com \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=wenjia@linux.ibm.com \
--cc=yhs@fb.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 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.