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

[David Ahern <dsahern@gmail.com>]

On 7/26/21 9:13 AM, Andrii Nakryiko wrote:
> On Mon, Jul 26, 2021 at 6:58 AM David Ahern <dsahern@gmail.com> wrote:
>>
>> On 7/23/21 6:25 PM, Andrii Nakryiko wrote:
>>>>>>>> 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.
>>>
>>>>
>>>> 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.
> 

xdp_l3fwd is built using an old school compile line - no CO-RE or BTF,
just a basic compile line extracted from samples/bpf 2-3 years ago.
Works fine for what I need and take this nothing more than an example to
verify your comment

"Libbpf already allows (and will keep allowing) multiple BPF programs
with SEC("xdp") in a single object file."


The bpftool command line to load the programs is:

$ bpftool -ddd prog loadall xdp_l3fwd.o /sys/fs/bpf

It fails because libbpf is trying to put 2 programs at the same path:

libbpf: pinned program '/sys/fs/bpf/xdp'
libbpf: failed to pin program: File exists
libbpf: unpinned program '/sys/fs/bpf/xdp'
Error: failed to pin all programs

The code that works is this:

SEC("xdp_l3fwd")
int xdp_l3fwd_prog(struct xdp_md *ctx)
{
        return xdp_l3fwd_flags(ctx, 0);
}

SEC("xdp_l3fwd_direct")
int xdp_l3fwd_direct_prog(struct xdp_md *ctx)
{
        return xdp_l3fwd_flags(ctx, BPF_FIB_LOOKUP_DIRECT);
}

The code that fails is this:

SEC("xdp")
int xdp_l3fwd_prog(struct xdp_md *ctx)
{
        return xdp_l3fwd_flags(ctx, 0);
}

SEC("xdp")
int xdp_l3fwd_direct_prog(struct xdp_md *ctx)
{
        return xdp_l3fwd_flags(ctx, BPF_FIB_LOOKUP_DIRECT);
}

which is what you said should work -- 2 programs with the same section name.

From a very quick check of bpftool vs libbpf, the former is calling
bpf_object__pin_programs from the latter and passing the base path
(/sys/fs/bpf in this example) and then bpf_object__pin_programs adds the
pin_name for the prog - which must be the same for both programs since
the second one fails.