Re: [bpf-next PATCH] bpf: libbpf, add kernel version section parsing back

Alexei Starovoitov wrote:

On Fri, Oct 18, 2019 at 9:52 AM Andrii Nakryiko [off-list ref] wrote:

quoted

On 10/18/19 7:41 AM, John Fastabend wrote:

quoted

With commit "libbpf: stop enforcing kern_version,..." we removed the
kernel version section parsing in favor of querying for the kernel
using uname() and populating the version using the result of the
query. After this any version sections were simply ignored.

Unfortunately, the world of kernels is not so friendly. I've found some
customized kernels where uname() does not match the in kernel version.
To fix this so programs can load in this environment this patch adds
back parsing the section and if it exists uses the user specified
kernel version to override the uname() result. However, keep most the
kernel uname() discovery bits so users are not required to insert the
version except in these odd cases.

Fixes: 5e61f27070292 ("libbpf: stop enforcing kern_version, populate it for users")
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---

In the name of not breaking users of weird kernels :)

Acked-by: Andrii Nakryiko <redacted>

What does it mean that uname is cheated?
Can libbpf read it from /proc/sys/kernel/osrelease ?
or /proc/version?
Is that read only or user space can somehow overwrite it?

In this case LINUX_VERSION_CODE as shown in version.h from linux-headers
does not much what is being reported by /proc/version or osrelease.

So its a bit surprising to me as well but I haven't got to the bottom
of it. Maybe something to do with how proc is mounted in this kubernetes
setup?