[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f4777af7e0b47b41760da5f291a7535c7006adf9.camel@gmail.com>
Date: Mon, 27 Nov 2023 23:32:35 +0200
From: Eduard Zingerman <eddyz87@...il.com>
To: Daniel Xu <dxu@...uu.xyz>, Yonghong Song <yonghong.song@...ux.dev>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>,
Shuah Khan <shuah@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Alexei Starovoitov <ast@...nel.org>,
Steffen Klassert <steffen.klassert@...unet.com>,
antony.antony@...unet.com, Mykola Lysenko <mykolal@...com>,
Martin KaFai Lau <martin.lau@...ux.dev>,
Song Liu <song@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>,
Stanislav Fomichev <sdf@...gle.com>,
Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
bpf <bpf@...r.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, devel@...ux-ipsec.org,
Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH ipsec-next v1 6/7] bpf: selftests: test_tunnel: Disable
CO-RE relocations
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
Powered by blists - more mailing lists