lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 22 Mar 2024 21:36:58 +0800
From: Tao Chen <chen.dylane@...il.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Andrii Nakryiko <andrii@...nel.org>, Alexei Starovoitov <ast@...nel.org>,
 Daniel Borkmann <daniel@...earbox.net>,
 Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>,
 Yonghong Song <yonghong.song@...ux.dev>,
 John Fastabend <john.fastabend@...il.com>, bpf@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] libbpf: add specific btf name info when do core

Hi, Nakryiko, thank you for your reply. I try to familiarize with core 
in libbpf, the debug info is really helpful for me. But i use the old 
kernel btf, so origion debuginfo like:
  struct task_struct___x: found target candidate [130] struct 
task_struct in [vmlinux]
I think it may be more clear, if we print btf name when we use old 
kernel btf like:
  struct task_struct___x: found target candidate [130] struct 
task_struct in [/boot/***.btf]
The patch just solve debug info show for newbies above.

在 2024/3/22 上午2:52, Andrii Nakryiko 写道:
> On Thu, Mar 21, 2024 at 10:04 AM Tao Chen <chen.dylane@...il.com> wrote:
>>
>> No logic changed, just add specific btf name when core info
>> print, maybe it seems more understandable.
>>
>> Signed-off-by: Tao Chen <chen.dylane@...il.com>
>> ---
>>   tools/lib/bpf/libbpf.c | 14 +++++++++-----
>>   1 file changed, 9 insertions(+), 5 deletions(-)
>>
> 
> Can you elaborate on what problem you are trying to solve?
> Conceptually libbpf does look for types in vmlinux (meaning main
> kernel BTF), even if user overrides BTF location (presumably because
> of old kernel). So even when we emit "vmlinux" in logs, it seems
> correct.
> 
> pw-bot: cr
> 
> 
>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>> index afd09571c482..b32154288b4a 100644
>> --- a/tools/lib/bpf/libbpf.c
>> +++ b/tools/lib/bpf/libbpf.c
>> @@ -5653,7 +5653,8 @@ static int load_module_btfs(struct bpf_object *obj)
>>   }
>>
>>   static struct bpf_core_cand_list *
>> -bpf_core_find_cands(struct bpf_object *obj, const struct btf *local_btf, __u32 local_type_id)
>> +bpf_core_find_cands(struct bpf_object *obj, const struct btf *local_btf, __u32 local_type_id,
>> +                   const char *targ_btf_path)
>>   {
>>          struct bpf_core_cand local_cand = {};
>>          struct bpf_core_cand_list *cands;
>> @@ -5680,7 +5681,8 @@ bpf_core_find_cands(struct bpf_object *obj, const struct btf *local_btf, __u32 l
>>
>>          /* Attempt to find target candidates in vmlinux BTF first */
>>          main_btf = obj->btf_vmlinux_override ?: obj->btf_vmlinux;
>> -       err = bpf_core_add_cands(&local_cand, local_essent_len, main_btf, "vmlinux", 1, cands);
>> +       err = bpf_core_add_cands(&local_cand, local_essent_len, main_btf,
>> +                                targ_btf_path ?: "vmlinux", 1, cands);
>>          if (err)
>>                  goto err_out;
>>
>> @@ -5793,7 +5795,8 @@ static int bpf_core_resolve_relo(struct bpf_program *prog,
>>                                   int relo_idx,
>>                                   const struct btf *local_btf,
>>                                   struct hashmap *cand_cache,
>> -                                struct bpf_core_relo_res *targ_res)
>> +                                struct bpf_core_relo_res *targ_res,
>> +                                const char *targ_btf_path)
>>   {
>>          struct bpf_core_spec specs_scratch[3] = {};
>>          struct bpf_core_cand_list *cands = NULL;
>> @@ -5813,7 +5816,7 @@ static int bpf_core_resolve_relo(struct bpf_program *prog,
>>
>>          if (relo->kind != BPF_CORE_TYPE_ID_LOCAL &&
>>              !hashmap__find(cand_cache, local_id, &cands)) {
>> -               cands = bpf_core_find_cands(prog->obj, local_btf, local_id);
>> +               cands = bpf_core_find_cands(prog->obj, local_btf, local_id, targ_btf_path);
>>                  if (IS_ERR(cands)) {
>>                          pr_warn("prog '%s': relo #%d: target candidate search failed for [%d] %s %s: %ld\n",
>>                                  prog_name, relo_idx, local_id, btf_kind_str(local_type),
>> @@ -5920,7 +5923,8 @@ bpf_object__relocate_core(struct bpf_object *obj, const char *targ_btf_path)
>>                          if (prog->obj->gen_loader)
>>                                  continue;
>>
>> -                       err = bpf_core_resolve_relo(prog, rec, i, obj->btf, cand_cache, &targ_res);
>> +                       err = bpf_core_resolve_relo(prog, rec, i, obj->btf, cand_cache, &targ_res,
>> +                                                   targ_btf_path);
>>                          if (err) {
>>                                  pr_warn("prog '%s': relo #%d: failed to relocate: %d\n",
>>                                          prog->name, i, err);
>> --
>> 2.34.1
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ