Re: [RFC PATCH bpf-next v3 2/2] selftests/bpf: add tests for selective kmod BTF loading

On Thu, Aug 20, 2026 at 8:51 PM Fuyu Zhao <[email protected]> wrote:
>
>
>
> On 8/21/2026 8:10 AM, Eduard Zingerman wrote:
> > On Wed, 2026-08-19 at 17:04 +0800, Fuyu Zhao wrote:
> >
> > ...
> >
> >> +++ b/tools/testing/selftests/bpf/prog_tests/kmod_btfs.c
> >> @@ -0,0 +1,196 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +#include <test_progs.h>
> >> +#include "kmod_btfs.skel.h"
> >> +
> >> +static bool btf_skipped;
> >> +static bool dup_ignored;
> >> +
> >> +static const char btf_skip_fmt[] =
> >> +    "libbpf: skipping module BTF '%s', not in kmod_btf_names\n";
> >> +static const char dup_ignore_fmt[] =
> >> +    "libbpf: duplicate kmod BTF name '%s' ignored\n";
> >> +
> >> +static int libbpf_print_cb(enum libbpf_print_level level, const char *fmt,
> >> +                       va_list args)
> >> +{
> >> +    if (!strcmp(fmt, btf_skip_fmt)) {
> >> +            if (!strcmp(va_arg(args, char *), "bpf_test_no_cfi"))
> >> +                    btf_skipped = true;
> >> +    } else if (!strcmp(fmt, dup_ignore_fmt)) {
> >> +            if (!strcmp(va_arg(args, char *), "bpf_testmod"))
> >> +                    dup_ignored = true;
> >> +    }
> >> +
> >> +    return 0;
> >> +}
> >
> > Idk what Andrii would say about this, but I'd rather add an internal
> > function akin to:
> >
> >   size_t bpf_object_btf_module_cnt(const struct bpf_object *obj);
> >
> > in libbpf.c and expose it via libbpf_internal.h (*not* via API),
> > instead of intercepting log messages.
> >
> > ...
>
> I think your suggestion is better. It also addresses the issue raised by
> the bot about potentially hiding other libbpf logs. I'll wait for Andrii's
> feedback on this.
>

I would do neither and just not validate explicitly that we skipped
(or not) some module. Instead, I'd see if it's simple and maintainable
to do a functional test: try to attach to a func or have relocation
fail against a type of a test module you explicitly do not allow to
load. If that succeeds, bad. Also have positive and negative tests to
show this custom kernel module list makes a difference as promised.

And try to keep the boilerplate to a minimum with all this, don't go overboard.

> Thanks,
> Fuyu
>