BPF List
 help / color / mirror / Atom feed
From: Alan Maguire <alan.maguire@oracle.com>
To: Eduard Zingerman <eddyz87@gmail.com>, andrii@kernel.org, ast@kernel.org
Cc: daniel@iogearbox.net, martin.lau@linux.dev, song@kernel.org,
	yonghong.song@linux.dev, john.fastabend@gmail.com,
	kpsingh@kernel.org, sdf@google.com, haoluo@google.com,
	jolsa@kernel.org, mcgrof@kernel.org, masahiroy@kernel.org,
	nathan@kernel.org, mykolal@fb.com, dxu@dxuuu.xyz,
	bpf@vger.kernel.org
Subject: Re: [PATCH v6 bpf-next 8/9] libbpf,bpf: share BTF relocate-related code with kernel
Date: Mon, 17 Jun 2024 14:31:02 +0100	[thread overview]
Message-ID: <78d4775c-2b26-4eec-a032-a0d61052395b@oracle.com> (raw)
In-Reply-To: <3a1dd525bee2875f370e73a0416d115018ed7e52.camel@gmail.com>

On 14/06/2024 23:49, Eduard Zingerman wrote:
> On Thu, 2024-06-13 at 10:50 +0100, Alan Maguire wrote:
>> Share relocation implementation with the kernel.  As part of this,
>> we also need the type/string iteration functions so add them to a
>> btf_iter.c file that also gets shared with the kernel. Relocation
>> code in kernel and userspace is identical save for the impementation
>> of the reparenting of split BTF to the relocated base BTF and
>> retrieval of BTF header from "struct btf"; these small functions
>> need separate user-space and kernel implementations.
>>
>> One other wrinkle on the kernel side is we have to map .BTF.ids in
>> modules as they were generated with the type ids used at BTF encoding
>> time. btf_relocate() optionally returns an array mapping from old BTF
>> ids to relocated ids, so we use that to fix up these references where
>> needed for kfuncs.
>>
>> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> 
> Hi Alan,
> 
> I've looked through this patch and all seems to look good,
> two minor notes below.
> 
> Thanks,
> Eduard
> 
> [...]
> 
>> @@ -8133,21 +8207,15 @@ static int btf_populate_kfunc_set(struct btf *btf, enum btf_kfunc_hook hook,
>>  		goto end;
>>  	}
>>  
>> -	/* We don't need to allocate, concatenate, and sort module sets, because
>> -	 * only one is allowed per hook. Hence, we can directly assign the
>> -	 * pointer and return.
>> -	 */
>> -	if (!vmlinux_set) {
>> -		tab->sets[hook] = add_set;
>> -		goto do_add_filter;
>> -	}
>> -
> 
> Is it necessary to adjust btf_free_kfunc_set_tab()? It currently skips
> freeing tab->sets[*] for modules. I've added two printk's and it looks
> like sets allocated for module here are leaking after insmod/rmmod.
>

great catch! I think we need

diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index da70914264fa..ef793731d40f 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -1676,14 +1676,8 @@ static void btf_free_kfunc_set_tab(struct btf *btf)

        if (!tab)
                return;
-       /* For module BTF, we directly assign the sets being registered, so
-        * there is nothing to free except kfunc_set_tab.
-        */
-       if (btf_is_module(btf))
-               goto free_tab;
        for (hook = 0; hook < ARRAY_SIZE(tab->sets); hook++)
                kfree(tab->sets[hook]);
-free_tab:
        kfree(tab);
        btf->kfunc_set_tab = NULL;
 }


>>  	/* In case of vmlinux sets, there may be more than one set being
>>  	 * registered per hook. To create a unified set, we allocate a new set
>>  	 * and concatenate all individual sets being registered. While each set
>>  	 * is individually sorted, they may become unsorted when concatenated,
>>  	 * hence re-sorting the final set again is required to make binary
>>  	 * searching the set using btf_id_set8_contains function work.
>> +	 *
>> +	 * For module sets, we need to allocate as we may need to relocate
>> +	 * BTF ids.
>>  	 */
>>  	set_cnt = set ? set->cnt : 0;
>>  
> 
> [...]
> 
>> @@ -8451,6 +8522,13 @@ int register_btf_id_dtor_kfuncs(const struct btf_id_dtor_kfunc *dtors, u32 add_c
>>  	btf->dtor_kfunc_tab = tab;
>>  
>>  	memcpy(tab->dtors + tab->cnt, dtors, add_cnt * sizeof(tab->dtors[0]));
>> +
>> +	/* remap BTF ids based on BTF relocation (if any) */
>> +	for (i = tab_cnt; i < tab_cnt + add_cnt; i++) {
>> +		tab->dtors[i].btf_id = btf_relocate_id(btf, tab->dtors[i].btf_id);
>> +		tab->dtors[i].kfunc_btf_id = btf_relocate_id(btf, tab->dtors[i].kfunc_btf_id);
> 
> The register_btf_id_dtor_kfuncs() is exported and thus could to be
> called from the modules, that's why you update it, right?
> Do we want to add such call to bpf_testmod? Currently, with kernel
> config used for selftests, I see only identity mappings.
>


Yep, we don't currently have coverage for dtors in bpf_testmod. I'll
look at adding that. Thanks!

Alan

  reply	other threads:[~2024-06-17 13:31 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-13  9:50 [PATCH v6 bpf-next 0/9] bpf: support resilient split BTF Alan Maguire
2024-06-13  9:50 ` [PATCH v6 bpf-next 1/9] libbpf: add btf__distill_base() creating split BTF with distilled base BTF Alan Maguire
2024-06-28 23:30   ` Andrii Nakryiko
2024-06-13  9:50 ` [PATCH v6 bpf-next 2/9] selftests/bpf: test distilled base, split BTF generation Alan Maguire
2024-06-13  9:50 ` [PATCH v6 bpf-next 3/9] libbpf: split BTF relocation Alan Maguire
2024-06-14  0:26   ` Eduard Zingerman
2024-06-17 21:50   ` Andrii Nakryiko
2024-06-18  9:47     ` Alan Maguire
2024-08-09 22:30   ` Neill Kapron
2024-08-10  9:37     ` Alan Maguire
2024-06-13  9:50 ` [PATCH v6 bpf-next 4/9] selftests/bpf: extend distilled BTF tests to cover " Alan Maguire
2024-06-14  1:13   ` Eduard Zingerman
2024-06-13  9:50 ` [PATCH v6 bpf-next 5/9] libbpf: make btf_parse_elf process .BTF.base transparently Alan Maguire
2024-06-13  9:50 ` [PATCH v6 bpf-next 6/9] resolve_btfids: handle presence of .BTF.base section Alan Maguire
2024-06-14  1:19   ` Eduard Zingerman
2024-06-13  9:50 ` [PATCH v6 bpf-next 7/9] module, bpf: store BTF base pointer in struct module Alan Maguire
2024-06-17 21:50   ` Andrii Nakryiko
2024-06-13  9:50 ` [PATCH v6 bpf-next 8/9] libbpf,bpf: share BTF relocate-related code with kernel Alan Maguire
2024-06-14 22:49   ` Eduard Zingerman
2024-06-17 13:31     ` Alan Maguire [this message]
2024-06-17 16:46       ` Eduard Zingerman
2024-06-13  9:50 ` [PATCH v6 bpf-next 9/9] kbuild,bpf: add module-specific pahole flags for distilled base BTF Alan Maguire
2024-06-17 21:50 ` [PATCH v6 bpf-next 0/9] bpf: support resilient split BTF Andrii Nakryiko
2024-06-17 22:00 ` patchwork-bot+netdevbpf

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=78d4775c-2b26-4eec-a032-a0d61052395b@oracle.com \
    --to=alan.maguire@oracle.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dxu@dxuuu.xyz \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=masahiroy@kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mykolal@fb.com \
    --cc=nathan@kernel.org \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox