From: Jiri Olsa <olsajiri@gmail.com>
To: Viktor Malik <vmalik@redhat.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Alexey Dobriyan <adobriyan@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>
Subject: Re: [PATCH bpf-next v2 1/2] tools/resolve_btfids: Refactor set sorting with types from btf_ids.h
Date: Fri, 2 Feb 2024 14:06:40 +0100 [thread overview]
Message-ID: <Zbzo4HBVmmkikbhO@krava> (raw)
In-Reply-To: <eafd46de2ff1bfc6103ec466d4fba0861ce416a6.1706717857.git.vmalik@redhat.com>
On Wed, Jan 31, 2024 at 05:24:08PM +0100, Viktor Malik wrote:
> Instead of using magic offsets to access BTF ID set data, leverage types
> from btf_ids.h (btf_id_set and btf_id_set8) which define the actual
> layout of the data. Thanks to this change, set sorting should also
> continue working if the layout changes.
>
> This requires to sync the definition of 'struct btf_id_set8' from
> include/linux/btf_ids.h to tools/include/linux/btf_ids.h. We don't sync
> the rest of the file at the moment, b/c that would require to also sync
> multiple dependent headers and we don't need any other defs from
> btf_ids.h.
>
> Signed-off-by: Viktor Malik <vmalik@redhat.com>
> ---
> tools/bpf/resolve_btfids/main.c | 30 ++++++++++++++++++++++--------
> tools/include/linux/btf_ids.h | 9 +++++++++
> 2 files changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/main.c
> index 27a23196d58e..7badf1557e5c 100644
> --- a/tools/bpf/resolve_btfids/main.c
> +++ b/tools/bpf/resolve_btfids/main.c
> @@ -70,6 +70,7 @@
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <errno.h>
> +#include <linux/btf_ids.h>
> #include <linux/rbtree.h>
> #include <linux/zalloc.h>
> #include <linux/err.h>
> @@ -78,7 +79,7 @@
> #include <subcmd/parse-options.h>
>
> #define BTF_IDS_SECTION ".BTF_ids"
> -#define BTF_ID "__BTF_ID__"
> +#define BTF_ID_PREFIX "__BTF_ID__"
nit does not look necessary to me
>
> #define BTF_STRUCT "struct"
> #define BTF_UNION "union"
> @@ -161,7 +162,7 @@ static int eprintf(int level, int var, const char *fmt, ...)
>
> static bool is_btf_id(const char *name)
> {
> - return name && !strncmp(name, BTF_ID, sizeof(BTF_ID) - 1);
> + return name && !strncmp(name, BTF_ID_PREFIX, sizeof(BTF_ID_PREFIX) - 1);
> }
>
> static struct btf_id *btf_id__find(struct rb_root *root, const char *name)
> @@ -441,7 +442,7 @@ static int symbols_collect(struct object *obj)
> * __BTF_ID__TYPE__vfs_truncate__0
> * prefix = ^
> */
> - prefix = name + sizeof(BTF_ID) - 1;
> + prefix = name + sizeof(BTF_ID_PREFIX) - 1;
>
> /* struct */
> if (!strncmp(prefix, BTF_STRUCT, sizeof(BTF_STRUCT) - 1)) {
> @@ -656,8 +657,8 @@ static int sets_patch(struct object *obj)
> while (next) {
> unsigned long addr, idx;
> struct btf_id *id;
> - int *base;
> - int cnt;
> + void *base;
> + int cnt, size;
>
> id = rb_entry(next, struct btf_id, rb_node);
> addr = id->addr[0];
> @@ -671,13 +672,26 @@ static int sets_patch(struct object *obj)
> }
>
> idx = idx / sizeof(int);
> - base = &ptr[idx] + (id->is_set8 ? 2 : 1);
> - cnt = ptr[idx];
> + if (id->is_set) {
> + struct btf_id_set *set;
> +
> + set = (struct btf_id_set *)&ptr[idx];
> + base = set->ids;
> + cnt = set->cnt;
> + size = sizeof(set->ids[0]);
> + } else {
> + struct btf_id_set8 *set8;
> +
> + set8 = (struct btf_id_set8 *)&ptr[idx];
> + base = set8->pairs;
> + cnt = set8->cnt;
> + size = sizeof(set8->pairs[0]);
> + }
>
> pr_debug("sorting addr %5lu: cnt %6d [%s]\n",
> (idx + 1) * sizeof(int), cnt, id->name);
>
> - qsort(base, cnt, id->is_set8 ? sizeof(uint64_t) : sizeof(int), cmp_id);
> + qsort(base, cnt, size, cmp_id);
maybe we could call qsort on top of each set type, seems simpler:
while (next) {
+ struct btf_id_set8 *set8;
+ struct btf_id_set *set;
unsigned long addr, idx;
struct btf_id *id;
- int *base;
- int cnt;
id = rb_entry(next, struct btf_id, rb_node);
addr = id->addr[0];
@@ -671,13 +672,16 @@ static int sets_patch(struct object *obj)
}
idx = idx / sizeof(int);
- base = &ptr[idx] + (id->is_set8 ? 2 : 1);
- cnt = ptr[idx];
+ if (id->is_set) {
+ set = (struct btf_id_set *)&ptr[idx];
+ qsort(set->ids, set->cnt, sizeof(set->ids[0]), cmp_id);
+ } else {
+ set8 = (struct btf_id_set8 *)&ptr[idx];
+ qsort(set8->pairs, set8->cnt, sizeof(set8->pairs[0]), cmp_id);
+ }
pr_debug("sorting addr %5lu: cnt %6d [%s]\n",
- (idx + 1) * sizeof(int), cnt, id->name);
-
- qsort(base, cnt, id->is_set8 ? sizeof(uint64_t) : sizeof(int), cmp_id);
+ (idx + 1) * sizeof(int), id->is_set ? set->cnt : set8->cnt, id->name);
next = rb_next(next);
}
jirka
next prev parent reply other threads:[~2024-02-02 13:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-31 16:24 [PATCH bpf-next v2 0/2] tools/resolve_btfids: fix cross-compilation to non-host endianness Viktor Malik
2024-01-31 16:24 ` [PATCH bpf-next v2 1/2] tools/resolve_btfids: Refactor set sorting with types from btf_ids.h Viktor Malik
2024-02-01 15:51 ` Daniel Borkmann
2024-02-02 9:55 ` Viktor Malik
2024-02-02 13:06 ` Jiri Olsa [this message]
2024-02-05 5:42 ` Viktor Malik
2024-01-31 16:24 ` [PATCH bpf-next v2 2/2] tools/resolve_btfids: fix cross-compilation to non-host endianness Viktor Malik
2024-02-01 16:36 ` Daniel Borkmann
2024-02-02 9:59 ` Viktor Malik
2024-02-03 1:38 ` Daniel Xu
2024-02-03 18:48 ` Manu Bretelle
2024-02-05 5:40 ` Viktor Malik
2024-02-03 20:17 ` Jiri Olsa
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=Zbzo4HBVmmkikbhO@krava \
--to=olsajiri@gmail.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=vmalik@redhat.com \
--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;
as well as URLs for NNTP newsgroup(s).