Re: [PATCH bpf-next v8 00/10] Introduce unstable CT lookup helpers

[Kumar Kartikeya Dwivedi <memxor@gmail.com>]

On Sat, Feb 19, 2022 at 01:09:15PM IST, Alexander Egorenkov wrote:
>
> Hi Kartikeya,
>
> sorry if i wasn't clear in my first message but just to be sure
> we have no misunderstandings :)
>
> .BTF sections work on s390x with linux-next and nf_conntrack as well if
> the corresponding .BTF section is a part of the kernel module itself.
> I tested it myself by building a linux-next kernel and testing it with a
> KVM guest, i'm able to load nf_conntrack and it works.
>
> In contrast, in the case where the corresponding .BTF section is separate
> from the kernel module nf_conntrack, it fails with the message i
> provided in the first email.
>
> Therefore, my question is, does BTF for kernel modules work if the
> corresponding BTF section is NOT a part of the kernel module but instead
> is stored within the corresponding debuginfo file
> /usr/lib/debug/lib/modules/*/kernel/net/netfilter/nf_conntrack.ko.debug ?
>

Ah, I see, thanks for the clarification.

Currently module BTF is parsed during module load, so unless we can extend the
kernel to pass BTF from a separate debuginfo during modprobe, and associate it
with the loaded module, it won't work. You also won't be able to make the kfunc
call from BPF program, as it would require module BTF fd during prog load.

Still, we can probably remove the error and return 0 when btf == NULL, even if
Kconfig option CONFIG_DEBUG_INFO_BTF is set. I was assuming it would never be
the case that the option is set and btf is not available after successful
parsing, but clearly that is wrong.

If the BPF maintainers agree this is ok, feel free to send a fix to remove the
error.

> Thanks
> Regards
> Alex
>
>
>

--
Kartikeya