On 8/22/2026 2:55 AM, Andrii Nakryiko wrote:
> 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.
>
Ah, this looks like a better approach. I'll follow your suggestion while
keeping the tests minimal.
Thanks,
Fuyu
>> Thanks,
>> Fuyu
>>
