From: John Fastabend <john.fastabend@gmail.com>
To: Alexei Starovoitov <ast@fb.com>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>,
John Fastabend <john.fastabend@gmail.com>
Cc: Andrii Nakryiko <andriin@fb.com>, bpf <bpf@vger.kernel.org>,
Networking <netdev@vger.kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH bpf-next 1/2] libbpf: stop enforcing kern_version, populate it for users
Date: Fri, 04 Oct 2019 07:55:16 -0700 [thread overview]
Message-ID: <5d975d54abdfc_35a52afafc1345bcdb@john-XPS-13-9370.notmuch> (raw)
In-Reply-To: <fb67f98a-08b4-3184-22f8-7d3fb91c9515@fb.com>
Alexei Starovoitov wrote:
> On 10/4/19 7:32 AM, Andrii Nakryiko wrote:
> >> If we are not going to validate the section should we also skip collect'ing it?
> > Well, if user supplied version, we will parse and use it to override
> > out prepopulated one, so in that sense we do have validation.
> >
> > But I think it's fine just to drop it altogether. Will do in v3.
> >
>
> what about older kernel that still enforce it?
> May be populate it in bpf_attr while loading, but
> don't check it in elf from libbpf?
Yeah, guess I wasn't thinking clearly this morning. The way my BPF progs
are currently written we use the version section to populate the kver.
Easy enough to change though if we think its cleaner to use an attribute
to set it. Actually, seems better to pass via bpf_attr IMO because
currently we use defines to populate the version which is a bit ugly.
next prev parent reply other threads:[~2019-10-04 14:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-04 3:00 [PATCH bpf-next 0/2] Add new-style bpf_object__open APIs Andrii Nakryiko
2019-10-04 3:00 ` [PATCH bpf-next 1/2] libbpf: stop enforcing kern_version, populate it for users Andrii Nakryiko
2019-10-04 14:05 ` John Fastabend
2019-10-04 14:32 ` Andrii Nakryiko
2019-10-04 14:36 ` Alexei Starovoitov
2019-10-04 14:55 ` John Fastabend [this message]
2019-10-04 15:07 ` Andrii Nakryiko
2019-10-04 15:59 ` John Fastabend
2019-10-18 14:49 ` John Fastabend
2019-10-04 3:00 ` [PATCH bpf-next 2/2] libbpf: add bpf_object__open_{file,mem} w/ extensible opts 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:
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=5d975d54abdfc_35a52afafc1345bcdb@john-XPS-13-9370.notmuch \
--to=john.fastabend@gmail.com \
--cc=Kernel-team@fb.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=netdev@vger.kernel.org \
/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 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).