From: Dave Marchevsky <davemarchevsky@meta.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@kernel.org>,
Delyan Kratunov <delyank@meta.com>
Subject: Re: [PATCH bpf-next v4 10/24] bpf: Introduce local kptrs
Date: Fri, 4 Nov 2022 22:19:27 -0400 [thread overview]
Message-ID: <2929a091-8193-3f0b-93b1-9812b69cf388@meta.com> (raw)
In-Reply-To: <20221104075113.5ighwdvero4mugu7@apollo>
On 11/4/22 3:51 AM, Kumar Kartikeya Dwivedi wrote:
> On Fri, Nov 04, 2022 at 11:27:04AM IST, Alexei Starovoitov wrote:
>> On Thu, Nov 3, 2022 at 12:11 PM Kumar Kartikeya Dwivedi
>> <memxor@gmail.com> wrote:
>>>
>>> Introduce local kptrs, i.e. PTR_TO_BTF_ID that point to a type in
>>> program BTF. This is indicated by the presence of MEM_TYPE_LOCAL type
>>> tag in reg->type to avoid having to check btf_is_kernel when trying to
>>> match argument types in helpers.
>> ...
>>>
>>> + /* MEM is of a type from program BTF, not kernel BTF. This is used to
>>> + * tag PTR_TO_BTF_ID allocated using bpf_kptr_alloc.
>>> + */
>>> + MEM_TYPE_LOCAL = BIT(11 + BPF_BASE_TYPE_BITS),
>>> +
>>
>> I know we have bpf_core_type_id_local.
>> It sort-of makes sense in the context of the program.
>> type_id_local -> inside the program
>> type_id_kernel -> kernel
>>
>> but in the context of the verifier "local kptr" doesn't read right.
>> Especially in MEM_TYPE_LOCAL.
>
> Yes, "local kptr" is not the best name. "kptr to local type" is too verbose
> though, do you have any suggestions on what to call this?
>
>>
>> Also, since it applies to PTR_TO_BTF_ID, should it prefix with PTR_?
>> Probably MEM_ is actually cleaner.
>> And we're not consistent already with MEM_PERCPU.
>> We can live with this inconsistency for now.
>>
>> So how about we rename MEM_ALLOC to MEM_RINGBUF,
>> since it's special bpf_ringbuf_reserve() memory
>> and use MEM_ALLOC to indicate the memory that came from bpf_obj_new ?
>>
>
> Yes, it makes sense. I think Andrii has expressed the same wish to rename it to
> something similar to MEM_RINGBUF before in [0].
I like this idea as well. I've been poking on a small refactoring patchset in
the background which will get rid of (current) MEM_ALLOC anyways.
>
> [0]: https://lore.kernel.org/bpf/CAEf4BzYK939fgyc3LwNvoz3vPk2avyskP_3wRZO344irubXPtg@mail.gmail.com
>
>> ... which made me realize that the comment above should
>> s/bpf_kptr_alloc/bpf_obj_new/
>
> I'll fix the comment.
next prev parent reply other threads:[~2022-11-05 2:19 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-03 19:09 [PATCH bpf-next v4 00/24] Local kptrs, BPF linked lists Kumar Kartikeya Dwivedi
2022-11-03 19:09 ` [PATCH bpf-next v4 01/24] bpf: Document UAPI details for special BPF types Kumar Kartikeya Dwivedi
2022-11-03 20:38 ` David Vernet
2022-11-03 19:09 ` [PATCH bpf-next v4 02/24] bpf: Allow specifying volatile type modifier for kptrs Kumar Kartikeya Dwivedi
2022-11-03 20:45 ` David Vernet
2022-11-03 19:09 ` [PATCH bpf-next v4 03/24] bpf: Clobber stack slot when writing over spilled PTR_TO_BTF_ID Kumar Kartikeya Dwivedi
2022-11-03 19:09 ` [PATCH bpf-next v4 04/24] bpf: Fix slot type check in check_stack_write_var_off Kumar Kartikeya Dwivedi
2022-11-03 19:09 ` [PATCH bpf-next v4 05/24] bpf: Drop reg_type_may_be_refcounted_or_null Kumar Kartikeya Dwivedi
2022-11-03 21:55 ` David Vernet
2022-11-03 19:09 ` [PATCH bpf-next v4 06/24] bpf: Refactor kptr_off_tab into btf_record Kumar Kartikeya Dwivedi
2022-11-04 2:44 ` Alexei Starovoitov
2022-11-04 3:00 ` Alexei Starovoitov
2022-11-04 7:02 ` Kumar Kartikeya Dwivedi
2022-11-04 7:27 ` Kumar Kartikeya Dwivedi
2022-11-04 3:16 ` Alexei Starovoitov
2022-11-04 4:00 ` Alexei Starovoitov
2022-11-04 4:09 ` Alexei Starovoitov
2022-11-04 7:34 ` Kumar Kartikeya Dwivedi
2022-11-03 19:09 ` [PATCH bpf-next v4 07/24] bpf: Consolidate spin_lock, timer management " Kumar Kartikeya Dwivedi
2022-11-04 4:52 ` Alexei Starovoitov
2022-11-04 5:30 ` Alexei Starovoitov
2022-11-04 6:43 ` Kumar Kartikeya Dwivedi
2022-11-04 6:47 ` Kumar Kartikeya Dwivedi
2022-11-03 19:09 ` [PATCH bpf-next v4 08/24] bpf: Refactor map->off_arr handling Kumar Kartikeya Dwivedi
2022-11-03 19:09 ` [PATCH bpf-next v4 09/24] bpf: Support bpf_list_head in map values Kumar Kartikeya Dwivedi
2022-11-03 19:09 ` [PATCH bpf-next v4 10/24] bpf: Introduce local kptrs Kumar Kartikeya Dwivedi
2022-11-04 5:57 ` Alexei Starovoitov
2022-11-04 7:51 ` Kumar Kartikeya Dwivedi
2022-11-04 15:38 ` Alexei Starovoitov
2022-11-05 2:19 ` Dave Marchevsky [this message]
2022-11-03 19:10 ` [PATCH bpf-next v4 11/24] bpf: Recognize bpf_{spin_lock,list_head,list_node} in " Kumar Kartikeya Dwivedi
2022-11-03 19:10 ` [PATCH bpf-next v4 12/24] bpf: Verify ownership relationships for user BTF types Kumar Kartikeya Dwivedi
2022-11-03 19:10 ` [PATCH bpf-next v4 13/24] bpf: Support locking bpf_spin_lock in local kptr Kumar Kartikeya Dwivedi
2022-11-03 19:10 ` [PATCH bpf-next v4 14/24] bpf: Allow locking bpf_spin_lock global variables Kumar Kartikeya Dwivedi
2022-11-04 2:54 ` Dave Marchevsky
2022-11-04 7:56 ` Kumar Kartikeya Dwivedi
2022-11-03 19:10 ` [PATCH bpf-next v4 15/24] bpf: Rewrite kfunc argument handling Kumar Kartikeya Dwivedi
2022-11-03 19:10 ` [PATCH bpf-next v4 16/24] bpf: Drop kfunc bits from btf_check_func_arg_match Kumar Kartikeya Dwivedi
2022-11-03 19:10 ` [PATCH bpf-next v4 17/24] bpf: Support constant scalar arguments for kfuncs Kumar Kartikeya Dwivedi
2022-11-03 19:10 ` [PATCH bpf-next v4 18/24] bpf: Teach verifier about non-size constant arguments Kumar Kartikeya Dwivedi
2022-11-03 19:10 ` [PATCH bpf-next v4 19/24] bpf: Introduce bpf_obj_new Kumar Kartikeya Dwivedi
2022-11-04 2:37 ` Dave Marchevsky
2022-11-04 8:09 ` Kumar Kartikeya Dwivedi
2022-11-04 15:39 ` Alexei Starovoitov
2022-11-03 19:10 ` [PATCH bpf-next v4 20/24] bpf: Introduce bpf_obj_drop Kumar Kartikeya Dwivedi
2022-11-03 19:10 ` [PATCH bpf-next v4 21/24] bpf: Permit NULL checking pointer with non-zero fixed offset Kumar Kartikeya Dwivedi
2022-11-03 19:10 ` [PATCH bpf-next v4 22/24] bpf: Introduce single ownership BPF linked list API Kumar Kartikeya Dwivedi
2022-11-04 5:56 ` Dave Marchevsky
2022-11-04 7:42 ` Kumar Kartikeya Dwivedi
2022-11-05 2:15 ` Dave Marchevsky
2022-11-05 18:16 ` Alexei Starovoitov
2022-11-06 1:53 ` Kumar Kartikeya Dwivedi
2022-11-03 19:10 ` [PATCH bpf-next v4 23/24] selftests/bpf: Add __contains macro to bpf_experimental.h Kumar Kartikeya Dwivedi
2022-11-03 19:10 ` [PATCH bpf-next v4 24/24] selftests/bpf: Add BPF linked list API tests Kumar Kartikeya Dwivedi
2022-11-04 7:03 ` Dave Marchevsky
2022-11-04 7:14 ` Kumar Kartikeya Dwivedi
2022-11-04 5:00 ` [PATCH bpf-next v4 00/24] Local kptrs, BPF linked lists patchwork-bot+netdevbpf
2022-11-04 5:30 ` patchwork-bot+netdevbpf
2022-11-04 6:30 ` 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=2929a091-8193-3f0b-93b1-9812b69cf388@meta.com \
--to=davemarchevsky@meta.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=delyank@meta.com \
--cc=martin.lau@kernel.org \
--cc=memxor@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