Re: [RFC PATCH bpf-next v3 1/2] libbpf: support selective kernel module BTF loading via bpf_object_open_opts

[bot+bpf-ci@kernel.org]

[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index b749c01742ee..957415341caf 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -782,6 +782,13 @@ struct bpf_object {
>  	char *token_path;
>  	int token_fd;
>
> +	/* kernel module BTFs to load, as specified via bpf_object_open_opts */
> +	struct {
> +		char **names;
> +		size_t nr_names;
> +		struct hashmap *names_map;
> +	} *kmod_btfs;
> +

This isn't a bug, but since this holds module names rather than BTFs,
would a name like kmod_btf_filter read more clearly next to the existing
btf_modules field?

>  	char path[];
>  };

[ ... ]

> @@ -5851,6 +5858,121 @@ int bpf_core_add_cands(struct bpf_core_cand *local_cand,
>  	return 0;
>  }
>
> +static size_t mod_name_hash_fn(long key, void *ctx)
> +{
> +	return str_hash((char *)key);
> +}
> +
> +static bool mod_name_equal_fn(long key1, long key2, void *ctx)
> +{
> +	return strcmp((char *)key1, (char *)key2) == 0;
> +}

This isn't a bug, but these look identical to str_hash_fn()/str_equal_fn()
in btf_dump.c - would it be worth hoisting one copy into libbpf_internal.h
instead of adding a second pair?

[ ... ]


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/32236360082