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

[Fuyu Zhao]

On 8/22/2026 2:55 AM, Andrii Nakryiko wrote:
> On Thu, Aug 20, 2026 at 8:51 PM Fuyu Zhao <zhaofuyu@xxxxxxxx> 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.
> 

Ah, this looks like a better approach. I'll follow your suggestion while
keeping the tests minimal.

Thanks,
Fuyu

>> Thanks,
>> Fuyu
>>