From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Alexei Starovoitov <ast@fb.com>
Cc: John Fastabend <john.fastabend@gmail.com>,
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, 4 Oct 2019 08:07:40 -0700 [thread overview]
Message-ID: <CAEf4BzbUSQdYqce+gyjO7-VSrF45nqXuLBMU6qRd63LHD+-JLg@mail.gmail.com> (raw)
In-Reply-To: <fb67f98a-08b4-3184-22f8-7d3fb91c9515@fb.com>
On Fri, Oct 4, 2019 at 7:36 AM Alexei Starovoitov <ast@fb.com> 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?
That's what my change does. I pre-populate correct kernel version in
bpf_object->kern_version from uname(). If ELF has "version" section,
we still parse it and override bpf_object->kern_version.
bpf_object->kern_version then is always specified as part of
bpf_prog_load->kern_version.
So what we are discussing here is to not even look at user-provided
version, but just always specify correct current kernel version. So I
don't think we are going to break anything, except we might allow to
pass some programs that were failing before due to unspecified or zero
version.
So with that, do you think it's ok to get rid of version section altogether?
next prev parent reply other threads:[~2019-10-04 15:07 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
2019-10-04 15:07 ` Andrii Nakryiko [this message]
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=CAEf4BzbUSQdYqce+gyjO7-VSrF45nqXuLBMU6qRd63LHD+-JLg@mail.gmail.com \
--to=andrii.nakryiko@gmail.com \
--cc=Kernel-team@fb.com \
--cc=andriin@fb.com \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--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).