From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>, bpf <bpf@vger.kernel.org>,
Magnus Karlsson <magnus.karlsson@intel.com>,
Ciara Loftus <ciara.loftus@intel.com>
Subject: Re: [PATCH bpf-next] libbpf: demote log message about unrecognised data sections back down to debug
Date: Fri, 05 Nov 2021 15:34:13 +0100 [thread overview]
Message-ID: <87a6iismca.fsf@toke.dk> (raw)
In-Reply-To: <CAEf4BzYGjV5DQB7tqRkSKz6pz-3QtU7uSWQVNJMW4eSjnpF98A@mail.gmail.com>
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> On Thu, Nov 4, 2021 at 5:29 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> When loading a BPF object, libbpf will output a log message when it
>> encounters an unrecognised data section. Since commit
>> 50e09460d9f8 ("libbpf: Skip well-known ELF sections when iterating ELF")
>> they are printed at "info" level so they will show up on the console by
>> default.
>>
>> The rationale in the commit cited above is to "increase visibility" of such
>> errors, but there can be legitimate, and completely harmless, uses of extra
>> data sections. In particular, libxdp uses custom data sections to store
>
> What if we make those extra sections to be ".rodata.something" and
> ".data.something", but without ALLOC flag in ELF, so that libbpf won't
> create maps for them. Libbpf also will check that program code never
> references anything from those sections.
>
> The worry I have about allowing arbitrary sections is that if in the
> future we want to add other special sections, then we might run into a
> conflict with some applications. So having some enforced naming
> convention would help prevent this. WDYT?
Hmm, I see your point, but as the libxdp example shows, this has not
really been "disallowed" before. I.e., having these arbitrary sections
has worked just fine.
How about we do the opposite: claim a namespace for future libbpf
extensions and disallow (as in, hard fail) if anything unrecognised is
in those sections? For instance, this could be any section names
starting with .BPF?
-Toke
next prev parent reply other threads:[~2021-11-05 14:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-04 12:29 [PATCH bpf-next] libbpf: demote log message about unrecognised data sections back down to debug Toke Høiland-Jørgensen
2021-11-04 18:20 ` Yonghong Song
2021-11-04 21:16 ` Andrii Nakryiko
2021-11-05 14:34 ` Toke Høiland-Jørgensen [this message]
2021-11-05 18:41 ` Andrii Nakryiko
2021-11-08 12:16 ` Toke Høiland-Jørgensen
2021-11-10 1:13 ` Andrii Nakryiko
2021-11-10 11:27 ` Toke Høiland-Jørgensen
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a6iismca.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=ciara.loftus@intel.com \
--cc=daniel@iogearbox.net \
--cc=magnus.karlsson@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.