From: Song Liu <songliubraving@fb.com>
To: Andrii Nakryiko <andrii@kernel.org>
Cc: bpf <bpf@vger.kernel.org>, Networking <netdev@vger.kernel.org>,
"Alexei Starovoitov" <ast@fb.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Kernel Team <Kernel-team@fb.com>,
open list <linux-kernel@vger.kernel.org>,
"rafael@kernel.org" <rafael@kernel.org>,
"jeyu@kernel.org" <jeyu@kernel.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v2 bpf-next 1/5] bpf: add in-kernel split BTF support
Date: Sat, 7 Nov 2020 01:27:41 +0000 [thread overview]
Message-ID: <712CED9D-91E3-4CF1-AAFC-3E970582D06D@fb.com> (raw)
In-Reply-To: <20201106230228.2202-2-andrii@kernel.org>
> On Nov 6, 2020, at 3:02 PM, Andrii Nakryiko <andrii@kernel.org> wrote:
>
> Adjust in-kernel BTF implementation to support a split BTF mode of operation.
> Changes are mostly mirroring libbpf split BTF changes, with the exception of
> start_id being 0 for in-kernel implementation due to simpler read-only mode.
>
> Otherwise, for split BTF logic, most of the logic of jumping to base BTF,
> where necessary, is encapsulated in few helper functions. Type numbering and
> string offset in a split BTF are logically continuing where base BTF ends, so
> most of the high-level logic is kept without changes.
>
> Type verification and size resolution is only doing an added resolution of new
> split BTF types and relies on already cached size and type resolution results
> in the base BTF.
>
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
[...]
>
> @@ -600,8 +618,15 @@ static const struct btf_kind_operations *btf_type_ops(const struct btf_type *t)
>
> static bool btf_name_offset_valid(const struct btf *btf, u32 offset)
> {
> - return BTF_STR_OFFSET_VALID(offset) &&
> - offset < btf->hdr.str_len;
> + if (!BTF_STR_OFFSET_VALID(offset))
> + return false;
> +again:
> + if (offset < btf->start_str_off) {
> + btf = btf->base_btf;
> + goto again;
Can we do a while loop instead of "goto again;"?
> + }
> + offset -= btf->start_str_off;
> + return offset < btf->hdr.str_len;
> }
>
> static bool __btf_name_char_ok(char c, bool first, bool dot_ok)
> @@ -615,10 +640,25 @@ static bool __btf_name_char_ok(char c, bool first, bool dot_ok)
> return true;
> }
>
> +static const char *btf_str_by_offset(const struct btf *btf, u32 offset)
> +{
> +again:
> + if (offset < btf->start_str_off) {
> + btf = btf->base_btf;
> + goto again;
> + }
Maybe add a btf_find_base_btf(btf, offset) helper for this logic?
> +
> + offset -= btf->start_str_off;
> + if (offset < btf->hdr.str_len)
> + return &btf->strings[offset];
> +
> + return NULL;
> +}
> +
[...]
> }
>
> const char *btf_name_by_offset(const struct btf *btf, u32 offset)
> {
> - if (offset < btf->hdr.str_len)
> - return &btf->strings[offset];
> -
> - return NULL;
> + return btf_str_by_offset(btf, offset);
> }
IIUC, btf_str_by_offset() and btf_name_by_offset() are identical. Can we
just keep btf_name_by_offset()?
>
> const struct btf_type *btf_type_by_id(const struct btf *btf, u32 type_id)
> {
> - if (type_id > btf->nr_types)
> - return NULL;
> +again:
> + if (type_id < btf->start_id) {
> + btf = btf->base_btf;
> + goto again;
> + }
ditto, goto again..
[...]
next prev parent reply other threads:[~2020-11-07 1:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-06 23:02 [PATCH v2 bpf-next 0/5] Integrate kernel module BTF support Andrii Nakryiko
2020-11-06 23:02 ` [PATCH v2 bpf-next 1/5] bpf: add in-kernel split " Andrii Nakryiko
2020-11-07 1:27 ` Song Liu [this message]
2020-11-07 1:51 ` Andrii Nakryiko
2020-11-06 23:02 ` [PATCH v2 bpf-next 2/5] bpf: assign ID to vmlinux BTF and return extra info for BTF in GET_OBJ_INFO Andrii Nakryiko
2020-11-06 23:02 ` [PATCH v2 bpf-next 3/5] kbuild: build kernel module BTFs if BTF is enabled and pahole supports it Andrii Nakryiko
2020-11-06 23:02 ` [PATCH v2 bpf-next 4/5] bpf: load and verify kernel module BTFs Andrii Nakryiko
2020-11-07 14:09 ` Greg Kroah-Hartman
2020-11-06 23:02 ` [PATCH v2 bpf-next 5/5] tools/bpftool: add support for in-kernel and named BTF in `btf show` Andrii Nakryiko
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=712CED9D-91E3-4CF1-AAFC-3E970582D06D@fb.com \
--to=songliubraving@fb.com \
--cc=Kernel-team@fb.com \
--cc=acme@redhat.com \
--cc=andrii@kernel.org \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=gregkh@linuxfoundation.org \
--cc=jeyu@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rafael@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).