Re: [PATCH v4 bpf-next 00/10] libbpf: stricter BPF program section name handling

From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Andrii Nakryiko <andrii@kernel.org>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH v4 bpf-next 00/10] libbpf: stricter BPF program section name handling
Date: Tue, 28 Sep 2021 13:55:55 -0700	[thread overview]
Message-ID: <CAADnVQLyJ1VSXCLspsjFX46v190skVPzEpF1yMKdW7CDMPMwhw@mail.gmail.com> (raw)
In-Reply-To: <20210928161946.2512801-1-andrii@kernel.org>

On Tue, Sep 28, 2021 at 9:57 AM Andrii Nakryiko <andrii@kernel.org> wrote:
>
> Implement opt-in stricter BPF program section name (SEC()) handling logic. For
> a lot of supported ELF section names, enforce exact section name match with no
> arbitrary characters added at the end. See patch #9 for more details.
>
> To allow this, patches #2 through #4 clean up and preventively fix selftests,
> normalizing existing SEC() usage across multiple selftests. While at it, those
> patches also reduce the amount of remaining bpf_object__find_program_by_title()
> uses, which should be completely removed soon, given it's an API with
> ambiguous semantics and will be deprecated and eventually removed in libbpf 1.0.
>
> Patch #1 also introduces SEC("tc") as an alias for SEC("classifier"). "tc" is
> a better and less misleading name, so patch #3 replaces all classifier* uses
> with nice and short SEC("tc").
>
> Last patch is also fixing "sk_lookup/" definition to not require and not allow
> extra "/blah" parts after it, which serve no meaning.
>
> All the other patches are gradual internal libbpf changes to:
>   - allow this optional strict logic for ELF section name handling;
>   - allow new use case (for now for "struct_ops", but that could be extended
>     to, say, freplace definitions), in which it can be used stand-alone to
>     specify just type (SEC("struct_ops")), or also accept extra parameters
>     which can be utilized by libbpf to either get more data or double-check
>     valid use (e.g., SEC("struct_ops/dctcp_init") to specify desired
>     struct_ops operation that is supposed to be implemented);
>   - get libbpf's internal logic ready to allow other libraries and
>     applications to specify their custom handlers for ELF section name for BPF
>     programs. All the pieces are in place, the only thing preventing making
>     this as public libbpf API is reliance on internal type for specifying BPF
>     program load attributes. The work is planned to revamp related low-level
>     libbpf APIs, at which point it will be possible to just re-use such new
>     types for coordination between libbpf and custom handlers.
>
> These changes are a part of libbpf 1.0 effort ([0]). They are also intended to
> be applied on top of the previous preparatory series [1], so currently CI will
> be failing to apply them to bpf-next until that patch set is landed. Once it
> is landed, kernel-patches daemon will automatically retest this patch set.
>
>   [0] https://github.com/libbpf/libbpf/wiki/Libbpf:-the-road-to-v1.0#stricter-and-more-uniform-bpf-program-section-name-sec-handling
>   [1] https://patchwork.kernel.org/project/netdevbpf/list/?series=547675&state=*
>
> v3->v4:
>   - replace SEC("classifier*") with SEC("tc") (Daniel);

Applied. Thanks