From: Martin KaFai Lau <martin.lau@linux.dev>
To: Kui-Feng Lee <sinquersw@gmail.com>, thinker.li@gmail.com
Cc: kuifeng@meta.com, bpf@vger.kernel.org, ast@kernel.org,
song@kernel.org, kernel-team@meta.com, andrii@kernel.org
Subject: Re: [PATCH bpf-next v2 2/3] bpf: struct_ops supports more than one page for trampolines.
Date: Thu, 22 Feb 2024 21:25:01 -0800 [thread overview]
Message-ID: <b8bac273-27c7-485a-8e45-8825251d6d5a@linux.dev> (raw)
In-Reply-To: <25982f53-732e-4ce8-bbb2-3354f5684296@gmail.com>
On 2/22/24 7:01 PM, Kui-Feng Lee wrote:
>
>
>
> On 2/22/24 18:16, Martin KaFai Lau wrote:
>> On 2/22/24 5:35 PM, Kui-Feng Lee wrote:
>>>
>>>
>>> On 2/22/24 16:33, Martin KaFai Lau wrote:
>>>> On 2/21/24 2:59 PM, thinker.li@gmail.com wrote:
>>>>> @@ -531,10 +567,10 @@ static long bpf_struct_ops_map_update_elem(struct
>>>>> bpf_map *map, void *key,
>>>>> const struct btf_type *module_type;
>>>>> const struct btf_member *member;
>>>>> const struct btf_type *t = st_ops_desc->type;
>>>>> + void *image = NULL, *image_end = NULL;
>>>>> struct bpf_tramp_links *tlinks;
>>>>> void *udata, *kdata;
>>>>> int prog_fd, err;
>>>>> - void *image, *image_end;
>>>>> u32 i;
>>>>> if (flags)
>>>>> @@ -573,15 +609,14 @@ static long bpf_struct_ops_map_update_elem(struct
>>>>> bpf_map *map, void *key,
>>>>> udata = &uvalue->data;
>>>>> kdata = &kvalue->data;
>>>>> - image = st_map->image;
>>>>> - image_end = st_map->image + PAGE_SIZE;
>>>>> module_type = btf_type_by_id(btf_vmlinux, st_ops_ids[IDX_MODULE_ID]);
>>>>> for_each_member(i, t, member) {
>>>>> const struct btf_type *mtype, *ptype;
>>>>> struct bpf_prog *prog;
>>>>> struct bpf_tramp_link *link;
>>>>> - u32 moff;
>>>>> + u32 moff, tflags;
>>>>> + int tsize;
>>>>> moff = __btf_member_bit_offset(t, member) / 8;
>>>>> ptype = btf_type_resolve_ptr(st_map->btf, member->type, NULL);
>>>>> @@ -653,10 +688,38 @@ static long bpf_struct_ops_map_update_elem(struct
>>>>> bpf_map *map, void *key,
>>>>> &bpf_struct_ops_link_lops, prog);
>>>>> st_map->links[i] = &link->link;
>>>>> - err = bpf_struct_ops_prepare_trampoline(tlinks, link,
>>>>> - &st_ops->func_models[i],
>>>>> - *(void **)(st_ops->cfi_stubs + moff),
>>>>> - image, image_end);
>>>>> + tflags = BPF_TRAMP_F_INDIRECT;
>>>>> + if (st_ops->func_models[i].ret_size > 0)
>>>>> + tflags |= BPF_TRAMP_F_RET_FENTRY_RET;
>>>>> +
>>>>> + /* Compute the size of the trampoline */
>>>>> + tlinks[BPF_TRAMP_FENTRY].links[0] = link;
>>>>> + tlinks[BPF_TRAMP_FENTRY].nr_links = 1;
>>>>> + tsize = arch_bpf_trampoline_size(&st_ops->func_models[i],
>>>>> + tflags, tlinks, NULL);
>>>>> + if (tsize < 0) {
>>>>> + err = tsize;
>>>>> + goto reset_unlock;
>>>>> + }
>>>>> +
>>>>> + /* Allocate pages */
>>>>> + if (tsize > (unsigned long)image_end - (unsigned long)image) {
>>>>> + if (tsize > PAGE_SIZE) {
>>>>> + err = -E2BIG;
>>>>> + goto reset_unlock;
>>>>> + }
>>>>> + image = bpf_struct_ops_map_inc_image(st_map);
>>>>> + if (IS_ERR(image)) {
>>>>> + err = PTR_ERR(image);
>>>>> + goto reset_unlock;
>>>>> + }
>>>>> + image_end = image + PAGE_SIZE;
>>>>> + }
>>>>> +
>>>>> + err = arch_prepare_bpf_trampoline(NULL, image, image_end,
>>>>> + &st_ops->func_models[i],
>>>>> + tflags, tlinks,
>>>>> + *(void **)(st_ops->cfi_stubs + moff));
>>>>
>>>> I don't prefer to copy the BPF_TRAMP_F_* setting on tflags, tlinks, and the
>>>> arch_*_trampoline_*() logic from bpf_struct_ops_prepare_trampoline() which
>>>> is used by the bpf_dummy_ops for testing also. Considering struct_ops
>>>> supports kernel module now, in the future, it is better to move
>>>> bpf_dummy_ops out to the bpf_testmod somehow and avoid its
>>>> bpf_struct_ops_prepare_trampoline() usage. For now, it is still better to
>>>> keep bpf_struct_ops_prepare_trampoline() to be reusable by both.
>>>>
>>>> Have you thought about the earlier suggestion in v1 to do
>>>> arch_alloc_bpf_trampoline() in bpf_struct_ops_prepare_trampoline() instead
>>>> of copying codes from bpf_struct_ops_prepare_trampoline() to
>>>> bpf_struct_ops_map_update_elem()?
>>>>
>>>> Something like this (untested code):
>>>>
>>>> void *bpf_struct_ops_prepare_trampoline(struct bpf_tramp_links *tlinks,
>>>> struct bpf_tramp_link *link,
>>>> const struct btf_func_model *model,
>>>> void *stub_func, void *image,
>>>> u32 *image_off,
>>>> bool allow_alloc)
>>
>> To be a little more specific, the changes in bpf_struct_ops_map_update_elem()
>> could be mostly like this (untested):
>>
>> ret_image = bpf_struct_ops_prepare_trampoline(tlinks, link,
>> &st_ops->func_models[i],
>> *(void **)(st_ops->cfi_stubs + moff),
>> image, &image_off,
>> st_map->image_pages_cnt <
>> MAX_TRAMP_IMAGE_PAGES);
>> if (IS_ERR(ret_image))
>> goto reset_unlock;
>>
>> if (image != ret_image) {
>> image = ret_image;
>> st_map->image_pages[st_map->image_pages_cnt++] = image;
>> }
>>
>
> What I don't like is the memory management code was in two named
> functions, bpf_struct_ops_map_free_image() and
> bpf_struct_ops_map_inc_image().
bpf_struct_ops_map_inc_image() is not needed.
> Now, it falls apart. Allocate in one place, keep accounting in another
> place, and free yet at the 3rd place.
>
>>>
>>>
>>> How about pass a struct bpf_struct_ops_map to
>>> bpf_struct_ops_prepare_trampoline(). If the pointer of struct
>>> bpf_struct_ops_map is not NULL, try to allocate new pages for the map?
>>>
>>> For example,
>>>
>>> static int
>>> _bpf_struct_ops_prepare_trampoline(struct bpf_tramp_links *tlinks,
>>>
>>> struct bpf_tramp_link *link,
>>>
>>> const struct btf_func_model *model,
>>>
>>> void *stub_func, void *image,
>>> void *image_end,
>>> struct bpf_struct_ops_map *st_map)
>>> {
>>>
>>> ...
>>>
>>> if (!image || size > PAGE_SIZE - *image_off) {
>>> if (!st_map)
>>
>> Why only limit to st_map != NULL?
>>
>> arch_alloc_bpf_trampoline() is also called in bpf_dummy_ops.
>> If bpf_struct_ops_prepare_trampoline() can do the alloc, it may as well simplify
>> bpf_dummy_ops and just use bpf_struct_ops_prepare_trampoline() to alloc.
>
>
> Yes, it can save a few lines from bpf_dummy_ops. But, bpf_dummy_ops
> still need to free the memory. And, it doesn't pair alloc and free in
> the same function. Usually, paring alloc and free in the same function,
> nearby, or the same module is easier to understand.
It is not only about saving a few lines. It just does not make sense to
add all this complexity and another "_"bpf_struct_ops_prepare_trampoline()
variant to make it conform to the alloc/free pair idea. To be clear, I don't
see alloc/free pair is a must have in all cases. There are many situations that
non-alloc named function calls multiple kmalloc() in different places and
one xyz_free() releases everything. Even alloc/free is really preferred,
there has to be a better way or else need to make a trade off.
I suggested the high level ideal on making
bpf_struct_ops_prepare_trampoline() to allocate page. It can sure add a
bpf_struct_ops_free_trampoline() if you see fit to make it match with
bpf_struct_ops_prepare_trampoline() as alloc/free pair, for example,
void bpf_struct_ops_free_trampoline(void *image)
{
bpf_jit_uncharge_modmem(PAGE_SIZE);
arch_free_bpf_trampoline(image, PAGE_SIZE);
}
and make bpf_struct_ops_map_free_image() to use
bpf_struct_ops_free_trampoline()
static void bpf_struct_ops_map_free_image(struct bpf_struct_ops_map *st_map)
{
int i;
for (i = 0; i < st_map->image_pages_cnt; i++) {
bpf_struct_ops_free_trampoline(st_map->image_pages[i]);
st_map->image_pages[i] = NULL;
}
st_map->image_pages_cnt = 0;
}
Then it should work like alloc/free pair.
next prev parent reply other threads:[~2024-02-23 5:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-21 22:59 [PATCH bpf-next v2 0/3] Allow struct_ops maps with a large number of programs thinker.li
2024-02-21 22:59 ` [PATCH bpf-next v2 1/3] bpf, net: validate struct_ops when updating value thinker.li
2024-02-21 22:59 ` [PATCH bpf-next v2 2/3] bpf: struct_ops supports more than one page for trampolines thinker.li
2024-02-23 0:33 ` Martin KaFai Lau
2024-02-23 1:35 ` Kui-Feng Lee
2024-02-23 2:16 ` Martin KaFai Lau
2024-02-23 3:01 ` Kui-Feng Lee
2024-02-23 5:25 ` Martin KaFai Lau [this message]
2024-02-23 17:36 ` Kui-Feng Lee
2024-02-23 18:29 ` Kui-Feng Lee
2024-02-23 18:42 ` Martin KaFai Lau
2024-02-23 19:05 ` Kui-Feng Lee
2024-02-23 19:15 ` Martin KaFai Lau
2024-02-23 22:06 ` Kui-Feng Lee
2024-02-24 3:20 ` Martin KaFai Lau
2024-02-23 18:32 ` Martin KaFai Lau
2024-02-21 22:59 ` [PATCH bpf-next v2 3/3] selftests/bpf: Test struct_ops maps with a large number of program links thinker.li
2024-02-21 23:02 ` [PATCH bpf-next v2 0/3] Allow struct_ops maps with a large number of programs Kui-Feng Lee
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=b8bac273-27c7-485a-8e45-8825251d6d5a@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=kernel-team@meta.com \
--cc=kuifeng@meta.com \
--cc=sinquersw@gmail.com \
--cc=song@kernel.org \
--cc=thinker.li@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox