From: Eduard Zingerman <eddyz87@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
martin.lau@kernel.org, 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: Thu, 04 Jan 2024 01:51:37 +0200 [thread overview]
Message-ID: <2f889478e7fc787dee74816f9f374284a94a3041.camel@gmail.com> (raw)
In-Reply-To: <CAEf4Bzbj8Eeo=SNtRzk75ST8=BnPVJi9CNp4KKpPaT_fnhUymA@mail.gmail.com>
On Wed, 2024-01-03 at 15:17 -0800, Andrii Nakryiko wrote:
[...]
> > 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.
>
> Yes, but it's bpf_prog_info to get func_info (actually two calls due
> to how API is), parse func_info (pain without libbpf internal helpers
> from libbpf_internal.h, and with it's more coupling) to find subprog's
> func BTF ID and then check BTF.
>
> It's so painful that I don't think it's worth it given we'll test this
> in libbpf CI (and I did manual check locally as well).
>
> Also, nothing actually prevents us from not doing this if the kernel
> supports __arg_ctx natively, which is just a painful feature detector
> to write, using low-level APIs, which is why I decided that it's
> simpler to just do this unconditionally.
I agree that there is no need for feature detection in this case.
> > I think it's worth it to add such test, wdyt?
> >
>
> I feel like slacking and not adding this :) This will definitely fail
> in libbpf CI, if it's wrong.
Very few people look at libbpf CI results and those results would be
available only after sync.
Idk, I think that some form of testing is necessary for kernel CI.
Either this, or an additional job that executes selected set of tests
on old kernel.
next prev parent reply other threads:[~2024-01-03 23:51 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
2024-01-03 23:17 ` Andrii Nakryiko
2024-01-03 23:51 ` Eduard Zingerman [this message]
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=2f889478e7fc787dee74816f9f374284a94a3041.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii.nakryiko@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