All of lore.kernel.org
 help / color / mirror / Atom feed
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: Tue, 7 Jan 2025 15:24:51 -0800	[thread overview]
Message-ID: <f897692c-cbf2-4906-aa15-1661162621eb@linux.dev> (raw)
In-Reply-To: <20241223021036.GC36000@j66a10360.sqa.eu95>

On 12/22/24 6:10 PM, D. Wythe wrote:
> On Thu, Dec 19, 2024 at 02:43:30PM -0800, Martin KaFai Lau wrote:
>> On 12/17/24 6:44 PM, D. Wythe wrote:
>>> 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.
>>>   	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?
> 
> I think this might not work, as the core issue lies in the fact that
> bpf_struct_ops_smc_ops and smc_ops are located on different btf.
> Searching for one fisrt cannot lead to the inference of the other.

Take a look at btf_find_by_name_kind(btf, 1 /* from base_btf */, ...) and also 
btf_type_by_id(). It starts searching from the btf->base_btf which should be the 
btf_vmlinux here and should have the "struct smc_ops". Please try.

  reply	other threads:[~2025-01-07 23:25 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
2024-12-23  2:10     ` D. Wythe
2025-01-07 23:24       ` Martin KaFai Lau [this message]
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=f897692c-cbf2-4906-aa15-1661162621eb@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.