From: Hao Luo <haoluo@google.com>
To: netdev@vger.kernel.org, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Cc: Shuah Khan <shuah@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andriin@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>, KP Singh <kpsingh@chromium.org>,
Stanislav Fomichev <sdf@google.com>,
Quentin Monnet <quentin@isovalent.com>,
Hao Luo <haoluo@google.com>
Subject: [RFC PATCH bpf-next 0/2] BTF support for ksyms
Date: Wed, 15 Jul 2020 14:43:10 -0700 [thread overview]
Message-ID: <20200715214312.2266839-1-haoluo@google.com> (raw)
This patch series extends the previously add __ksym externs with btf
info.
Right now the __ksym externs are treated as pure 64-bit scalar value.
Libbpf replaces ld_imm64 insn of __ksym by its kernel address at load
time. This patch series extend those extern with their btf info. Note
that btf support for __ksym must come with the btf that has VARs encoded
to work properly. Therefore, these patches are tested against a btf
generated by a patched pahole, whose change will available in released
pahole soon.
There are a couple of design choices that I would like feedbacks from
bpf/btf experts.
1. Because the newly added pseudo_btf_id needs to carry both a kernel
address (64 bits) and a btf id (32 bits), I used the 'off' fields
of ld_imm insn to carry btf id. I wonder if this breaks anything or
if there is a better idea.
2. Since only a subset of vars are going to be encoded into the new
btf, if a ksym that doesn't find its btf id, it doesn't get
converted into pseudo_btf_id. It is still treated as pure scalar
value. But we require kernel btf to be loaded in libbpf if there is
any ksym in the bpf prog.
This is RFC as it requires pahole changes that encode kernel vars into
btf.
Hao Luo (2):
bpf: BTF support for __ksym externs
selftests/bpf: Test __ksym externs with BTF
include/uapi/linux/bpf.h | 37 ++++++++++----
kernel/bpf/verifier.c | 26 ++++++++--
tools/include/uapi/linux/bpf.h | 37 ++++++++++----
tools/lib/bpf/libbpf.c | 50 ++++++++++++++++++-
.../testing/selftests/bpf/prog_tests/ksyms.c | 2 +
.../testing/selftests/bpf/progs/test_ksyms.c | 14 ++++++
6 files changed, 143 insertions(+), 23 deletions(-)
--
2.27.0.389.gc38d7665816-goog
next reply other threads:[~2020-07-15 21:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-15 21:43 Hao Luo [this message]
2020-07-15 21:43 ` [RFC PATCH bpf-next 1/2] bpf: BTF support for __ksym externs Hao Luo
2020-07-20 5:22 ` Andrii Nakryiko
2020-07-20 17:03 ` Hao Luo
2020-07-15 21:43 ` [RFC PATCH bpf-next 2/2] selftests/bpf: Test __ksym externs with BTF Hao Luo
2020-07-20 5:28 ` Andrii Nakryiko
2020-07-20 20:28 ` Hao Luo
2020-07-21 2:37 ` Andrii Nakryiko
2020-07-21 16:45 ` Hao Luo
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=20200715214312.2266839-1-haoluo@google.com \
--to=haoluo@google.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kpsingh@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=quentin@isovalent.com \
--cc=sdf@google.com \
--cc=shuah@kernel.org \
--cc=songliubraving@fb.com \
--cc=yhs@fb.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 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).