Re: [PATCH iproute2] libbpf: fix attach of prog with multiple sections

On Mon, Jul 26, 2021 at 6:58 AM David Ahern [off-list ref] wrote:

On 7/23/21 6:25 PM, Andrii Nakryiko wrote:

quoted

quoted

quoted

quoted

quoted

quoted

This is still problematic, because one section can have multiple BPF
programs. I.e., it's possible two define two or more XDP BPF programs
all with SEC("xdp") and libbpf works just fine with that. I suggest
moving users to specify the program name (i.e., C function name
representing the BPF program). All the xdp_mycustom_suffix namings are
a hack and will be rejected by libbpf 1.0, so it would be great to get
a head start on fixing this early on.

Thanks for bringing this up. Currently, there is no way to specify a
function name with "tc exec bpf" (only a section name via the "sec" arg). So
probably, we should just add another arg to specify the function name.

How about add a "prog" arg to load specified program name and mark
"sec" as not recommended? To keep backwards compatibility we just load the
first program in the section.

Why not error out if there is more than one program with the same
section name? if there is just one (and thus section name is still
unique) -- then proceed. It seems much less confusing, IMO.

Let' see if I understand this correctly: libbpf 1.0 is not going to
allow SEC("xdp_foo") or SEC("xdp_bar") kind of section names - which is
the hint for libbpf to know program type. Instead only SEC("xdp") is
allowed.

Right.

quoted

Further, a single object file is not going to be allowed to have
multiple SEC("xdp") instances for each program name.

On the contrary. Libbpf already allows (and will keep allowing)
multiple BPF programs with SEC("xdp") in a single object file. Which
is why section_name is not a unique program identifier.

Does that require BTF? My attempts at loading an object file with 2
SEC("xdp") programs failed. This is using bpftool from top of tree and
loadall.

You mean kernel BTF? Not if XDP programs themselves were built
requiring CO-RE. So if those programs use #include "vmlinux.h", or
there is BPF_CORE_READ() use somewhere in the code, or explicit
__attribute__((preserve_access_index)) is used on some of the used
structs, then yes, vmlinux BTF will be needed. But otherwise no. Do
you have verbose error logs? I think with bpftool you can get them
with -d argument.