Netdev Archive on
help / color / mirror / Atom feed
From: David Ahern <>
To: Andrii Nakryiko <>
Cc: Hangbin Liu <>, Martynas Pumputis <>,
	Networking <>,
	Stephen Hemminger <>,
	Daniel Borkmann <>
Subject: Re: [PATCH iproute2] libbpf: fix attach of prog with multiple sections
Date: Mon, 26 Jul 2021 20:51:14 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 7/26/21 9:13 AM, Andrii Nakryiko wrote:
> On Mon, Jul 26, 2021 at 6:58 AM David Ahern <> 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:

int xdp_l3fwd_prog(struct xdp_md *ctx)
        return xdp_l3fwd_flags(ctx, 0);

int xdp_l3fwd_direct_prog(struct xdp_md *ctx)
        return xdp_l3fwd_flags(ctx, BPF_FIB_LOOKUP_DIRECT);

The code that fails is this:

int xdp_l3fwd_prog(struct xdp_md *ctx)
        return xdp_l3fwd_flags(ctx, 0);

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.

  reply	other threads:[~2021-07-27  2:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-05 12:43 Martynas Pumputis
2021-07-06  2:44 ` Hangbin Liu
2021-07-20 20:27 ` Andrii Nakryiko
2021-07-21 14:47   ` Martynas Pumputis
2021-07-21 14:59     ` David Ahern
2021-07-21 15:27       ` Martynas Pumputis
2021-07-23  4:01         ` Andrii Nakryiko
2021-07-23  4:41     ` Hangbin Liu
2021-07-23  4:51       ` Andrii Nakryiko
2021-07-23  7:55         ` Hangbin Liu
2021-07-23 16:09           ` Andrii Nakryiko
2021-07-24  8:12             ` Hangbin Liu
2021-07-24  0:12         ` David Ahern
2021-07-24  0:25           ` Andrii Nakryiko
2021-07-26 13:58             ` David Ahern
2021-07-26 15:13               ` Andrii Nakryiko
2021-07-27  2:51                 ` David Ahern [this message]
2021-07-27 19:05                   ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH iproute2] libbpf: fix attach of prog with multiple sections' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).