From: Eduard Zingerman <eddyz87@gmail.com>
To: Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
martin.lau@kernel.org
Cc: kernel-team@meta.com, Jiri Olsa <jolsa@kernel.org>
Subject: Re: [PATCH v2 bpf-next 9/9] selftests/bpf: add arg:ctx cases to test_global_funcs tests
Date: Wed, 03 Jan 2024 22:57:48 +0200 [thread overview]
Message-ID: <2e7306da990a9b7af22d2af271dacb9723b067fc.camel@gmail.com> (raw)
In-Reply-To: <20240102190055.1602698-10-andrii@kernel.org>
On Tue, 2024-01-02 at 11:00 -0800, Andrii Nakryiko wrote:
> Add a few extra cases of global funcs with context arguments. This time
> rely on "arg:ctx" decl_tag (__arg_ctx macro), but put it next to
> "classic" cases where context argument has to be of an exact type that
> BPF verifier expects (e.g., bpf_user_pt_regs_t for kprobe/uprobe).
>
> Colocating all these cases separately from other global func args that
> rely on arg:xxx decl tags (in verifier_global_subprogs.c) allows for
> simpler backwards compatibility testing on old kernels. All the cases in
> test_global_func_ctx_args.c are supposed to work on older kernels, which
> was manually validated during development.
>
> Acked-by: Jiri Olsa <jolsa@kernel.org>
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> ---
At first I thought that we would need to add a new CI job that would
run these tests for some older kernel version.
However, the transformation of the sub-program parameters happens
unconditionally. So it should be possible to read BTF for some of the
programs after they are loaded and check if transformation is applied
as expected. Thus allowing to check __arg_ctx handling on libbpf side
w/o the need to run on old kernel.
I think it's worth it to add such test, wdyt?
next prev parent reply other threads:[~2024-01-03 20:57 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-02 19:00 [PATCH v2 bpf-next 0/9] Libbpf-side __arg_ctx fallback support Andrii Nakryiko
2024-01-02 19:00 ` [PATCH v2 bpf-next 1/9] libbpf: name internal functions consistently Andrii Nakryiko
2024-01-03 23:12 ` Alexei Starovoitov
2024-01-03 23:17 ` Eduard Zingerman
2024-01-04 0:30 ` Andrii Nakryiko
2024-01-02 19:00 ` [PATCH v2 bpf-next 2/9] libbpf: make uniform use of btf__fd() accessor inside libbpf Andrii Nakryiko
2024-01-02 19:00 ` [PATCH v2 bpf-next 3/9] libbpf: use explicit map reuse flag to skip map creation steps Andrii Nakryiko
2024-01-02 19:00 ` [PATCH v2 bpf-next 4/9] libbpf: don't rely on map->fd as an indicator of map being created Andrii Nakryiko
2024-01-02 19:00 ` [PATCH v2 bpf-next 5/9] libbpf: use stable map placeholder FDs Andrii Nakryiko
2024-01-03 20:57 ` Eduard Zingerman
2024-01-03 22:46 ` Andrii Nakryiko
2024-01-02 19:00 ` [PATCH v2 bpf-next 6/9] libbpf: move exception callbacks assignment logic into relocation step Andrii Nakryiko
2024-01-02 19:00 ` [PATCH v2 bpf-next 7/9] libbpf: move BTF loading step after " Andrii Nakryiko
2024-01-02 19:00 ` [PATCH v2 bpf-next 8/9] libbpf: implement __arg_ctx fallback logic Andrii Nakryiko
2024-01-03 20:57 ` Eduard Zingerman
2024-01-03 23:10 ` Andrii Nakryiko
2024-01-03 23:43 ` Eduard Zingerman
2024-01-03 23:59 ` Andrii Nakryiko
2024-01-04 0:09 ` Eduard Zingerman
2024-01-04 0:27 ` Andrii Nakryiko
2024-01-02 19:00 ` [PATCH v2 bpf-next 9/9] selftests/bpf: add arg:ctx cases to test_global_funcs tests Andrii Nakryiko
2024-01-03 20:57 ` Eduard Zingerman [this message]
2024-01-03 23:17 ` Andrii Nakryiko
2024-01-03 23:51 ` Eduard Zingerman
2024-01-04 0:26 ` Andrii Nakryiko
2024-01-04 0:28 ` Eduard Zingerman
2024-01-02 19:57 ` [PATCH v2 bpf-next 0/9] Libbpf-side __arg_ctx fallback support Andrii Nakryiko
2024-01-03 20:57 ` Eduard Zingerman
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=2e7306da990a9b7af22d2af271dacb9723b067fc.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jolsa@kernel.org \
--cc=kernel-team@meta.com \
--cc=martin.lau@kernel.org \
/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