From: Eduard Zingerman <eddyz87@gmail.com>
To: Daniel Xu <dxu@dxuuu.xyz>, Yonghong Song <yonghong.song@linux.dev>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Shuah Khan <shuah@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Steffen Klassert <steffen.klassert@secunet.com>,
antony.antony@secunet.com, Mykola Lysenko <mykolal@fb.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, bpf <bpf@vger.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
devel@linux-ipsec.org,
Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH ipsec-next v1 6/7] bpf: selftests: test_tunnel: Disable CO-RE relocations
Date: Mon, 27 Nov 2023 23:32:35 +0200 [thread overview]
Message-ID: <f4777af7e0b47b41760da5f291a7535c7006adf9.camel@gmail.com> (raw)
In-Reply-To: <xehp2qvy5cyaairbnfhem4hvbsl26blo4zzu7z6ywbp26jcwyn@hgp3v2q4ud7o>
On Mon, 2023-11-27 at 14:45 -0600, Daniel Xu wrote:
[...]
> IIUC uapi structs look the same in BTF as any other struct.
Yes, and all share preserve_access_index attribute because of the way
attribute push/pop directives are generated in vmlinux.h.
> Just wondering, though: will bpftool be able to generate the appropriate
> annotations for uapi structs?
The problem is that there is no easy way to identify if structure is
uapi in DWARF (from which BTF is generated).
One way to do this:
- modify pahole to check DW_AT_decl_file for each struct DWARF entry
and generate some special decl tag in BTF;
- modify bpftool to interpret this tag as a marker to not generate
preserve_access_index for a structure.
The drawback is that such behavior hardcodes some kernel specific
assumptions both in pahole and in bpftool. It also remains to be seen
if DW_AT_decl_file tags are consistent.
It might be the case that allowing excessive CO-RE relocations is a
better option. (And maybe tweak something about bitfield access
generation to avoid such issues as in this thread).
Thanks,
Eduard
next prev parent reply other threads:[~2023-11-27 21:32 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-22 18:20 [PATCH ipsec-next v1 0/7] Add bpf_xdp_get_xfrm_state() kfunc Daniel Xu
2023-11-22 18:20 ` [PATCH ipsec-next v1 1/7] bpf: xfrm: " Daniel Xu
2023-11-22 23:26 ` Alexei Starovoitov
2023-11-25 20:36 ` Yonghong Song
2023-11-26 4:38 ` Daniel Xu
2023-11-22 18:20 ` [PATCH ipsec-next v1 2/7] bpf: xfrm: Add bpf_xdp_xfrm_state_release() kfunc Daniel Xu
2023-11-22 18:20 ` [PATCH ipsec-next v1 3/7] bpf: selftests: test_tunnel: Use ping -6 over ping6 Daniel Xu
2023-11-22 18:20 ` [PATCH ipsec-next v1 4/7] bpf: selftests: test_tunnel: Mount bpffs if necessary Daniel Xu
2023-11-22 18:20 ` [PATCH ipsec-next v1 5/7] bpf: selftests: test_tunnel: Use vmlinux.h declarations Daniel Xu
2023-11-26 0:34 ` Yonghong Song
2023-11-26 4:34 ` Daniel Xu
2023-11-22 18:20 ` [PATCH ipsec-next v1 6/7] bpf: selftests: test_tunnel: Disable CO-RE relocations Daniel Xu
2023-11-26 0:51 ` Yonghong Song
2023-11-26 0:54 ` Alexei Starovoitov
2023-11-26 4:22 ` Yonghong Song
2023-11-26 20:14 ` Eduard Zingerman
2023-11-27 0:04 ` Daniel Xu
2023-11-27 1:52 ` Eduard Zingerman
2023-11-27 5:44 ` Yonghong Song
2023-11-27 5:53 ` Yonghong Song
2023-11-27 20:45 ` Daniel Xu
2023-11-27 21:32 ` Eduard Zingerman [this message]
2023-11-28 0:01 ` Daniel Xu
2023-11-28 4:06 ` Yonghong Song
2023-11-28 16:02 ` Andrii Nakryiko
2023-11-28 16:13 ` Daniel Xu
2023-11-28 16:17 ` Daniel Xu
2023-11-28 16:56 ` Yonghong Song
2023-11-28 16:19 ` Eduard Zingerman
2023-11-27 5:20 ` Yonghong Song
2023-11-22 18:20 ` [PATCH ipsec-next v1 7/7] bpf: xfrm: Add selftest for bpf_xdp_get_xfrm_state() Daniel Xu
2023-11-22 23:28 ` Alexei Starovoitov
2023-11-24 20:59 ` Daniel Xu
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=f4777af7e0b47b41760da5f291a7535c7006adf9.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=antony.antony@secunet.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=devel@linux-ipsec.org \
--cc=dxu@dxuuu.xyz \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mykolal@fb.com \
--cc=netdev@vger.kernel.org \
--cc=sdf@google.com \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=yonghong.song@linux.dev \
/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).