From: Yonghong Song <yhs@meta.com>
To: Quentin Monnet <quentin@isovalent.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>
Cc: "Martin KaFai Lau" <martin.lau@linux.dev>,
"Song Liu" <song@kernel.org>, "Yonghong Song" <yhs@fb.com>,
"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@vger.kernel.org,
"Alexander Lobakin" <aleksander.lobakin@intel.com>,
"Michal Suchánek" <msuchanek@suse.de>,
"Alexander Lobakin" <alobakin@pm.me>
Subject: Re: [PATCH bpf-next 2/4] bpftool: define a local bpf_perf_link to fix accessing its fields
Date: Fri, 12 May 2023 07:47:47 -0700 [thread overview]
Message-ID: <40817aae-bb4b-31b7-6853-eb4d37ca2518@meta.com> (raw)
In-Reply-To: <20230512103354.48374-3-quentin@isovalent.com>
On 5/12/23 3:33 AM, Quentin Monnet wrote:
> From: Alexander Lobakin <alobakin@pm.me>
>
> When building bpftool with !CONFIG_PERF_EVENTS:
>
> skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type 'struct bpf_perf_link'
> perf_link = container_of(link, struct bpf_perf_link, link);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helpers.h:74:22: note: expanded from macro 'container_of'
> ((type *)(__mptr - offsetof(type, member))); \
> ^~~~~~~~~~~~~~~~~~~~~~
> tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helpers.h:68:60: note: expanded from macro 'offsetof'
> #define offsetof(TYPE, MEMBER) ((unsigned long)&((TYPE *)0)->MEMBER)
> ~~~~~~~~~~~^
> skeleton/pid_iter.bpf.c:44:9: note: forward declaration of 'struct bpf_perf_link'
> struct bpf_perf_link *perf_link;
> ^
>
> &bpf_perf_link is being defined and used only under the ifdef.
> Define struct bpf_perf_link___local with the `preserve_access_index`
> attribute inside the pid_iter BPF prog to allow compiling on any
> configs. CO-RE will substitute it with the real struct bpf_perf_link
> accesses later on.
> container_of() is not CO-REd, but it is a noop for
'container_of() is not CO-REd' is incorrect.
#define container_of(ptr, type, member) \
({ \
void *__mptr = (void *)(ptr); \
((type *)(__mptr - offsetof(type, member))); \
})
offsetof() will do necessary CO-RE relocation if the field is specified
with preserve_access_index attribute. So container_of will actually
do CO-RE relocation as well.
> bpf_perf_link <-> bpf_link and the local copy is a full mirror of
> the original structure.
>
> Fixes: cbdaf71f7e65 ("bpftool: Add bpf_cookie to link output")
> Suggested-by: Andrii Nakryiko <andrii@kernel.org>
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
> Signed-off-by: Quentin Monnet <quentin@isovalent.com>
> ---
> tools/bpf/bpftool/skeleton/pid_iter.bpf.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/tools/bpf/bpftool/skeleton/pid_iter.bpf.c b/tools/bpf/bpftool/skeleton/pid_iter.bpf.c
> index e2af8e5fb29e..3a4c4f7d83d8 100644
> --- a/tools/bpf/bpftool/skeleton/pid_iter.bpf.c
> +++ b/tools/bpf/bpftool/skeleton/pid_iter.bpf.c
> @@ -15,6 +15,11 @@ enum bpf_obj_type {
> BPF_OBJ_BTF,
> };
>
> +struct bpf_perf_link___local {
> + struct bpf_link link;
> + struct file *perf_file;
> +} __attribute__((preserve_access_index));
> +
> struct perf_event___local {
> u64 bpf_cookie;
> } __attribute__((preserve_access_index));
> @@ -45,10 +50,10 @@ static __always_inline __u32 get_obj_id(void *ent, enum bpf_obj_type type)
> /* could be used only with BPF_LINK_TYPE_PERF_EVENT links */
> static __u64 get_bpf_cookie(struct bpf_link *link)
> {
> + struct bpf_perf_link___local *perf_link;
> struct perf_event___local *event;
> - struct bpf_perf_link *perf_link;
>
> - perf_link = container_of(link, struct bpf_perf_link, link);
> + perf_link = container_of(link, struct bpf_perf_link___local, link);
> event = BPF_CORE_READ(perf_link, perf_file, private_data);
> return BPF_CORE_READ(event, bpf_cookie);
> }
next prev parent reply other threads:[~2023-05-12 14:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-12 10:33 [PATCH bpf-next 0/4] bpftool: Fix skeletons compilation for older kernels Quentin Monnet
2023-05-12 10:33 ` [PATCH bpf-next 1/4] bpftool: use a local copy of perf_event to fix accessing ::bpf_cookie Quentin Monnet
2023-05-12 10:33 ` [PATCH bpf-next 2/4] bpftool: define a local bpf_perf_link to fix accessing its fields Quentin Monnet
2023-05-12 14:47 ` Yonghong Song [this message]
2023-05-15 16:43 ` Quentin Monnet
2023-05-12 10:33 ` [PATCH bpf-next 3/4] bpftool: Use a local copy of BPF_LINK_TYPE_PERF_EVENT in pid_iter.bpf.c Quentin Monnet
2023-05-12 10:33 ` [PATCH bpf-next 4/4] bpftool: use a local bpf_perf_event_value to fix accessing its fields Quentin Monnet
2023-05-12 12:59 ` Jiri Olsa
2023-05-15 16:53 ` Quentin Monnet
2023-07-07 9:53 ` Quentin Monnet
2023-05-16 21:30 ` Andrii Nakryiko
2023-05-17 15:02 ` Quentin Monnet
2023-05-17 16:58 ` 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=40817aae-bb4b-31b7-6853-eb4d37ca2518@meta.com \
--to=yhs@meta.com \
--cc=aleksander.lobakin@intel.com \
--cc=alobakin@pm.me \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=msuchanek@suse.de \
--cc=quentin@isovalent.com \
--cc=sdf@google.com \
--cc=song@kernel.org \
--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