From: Eduard Zingerman <eddyz87@gmail.com>
To: Ihor Solodrai <ihor.solodrai@linux.dev>,
dwarves@vger.kernel.org, alan.maguire@oracle.com,
acme@kernel.org, andrii <andrii@kernel.org>,
Alexei Starovoitov <ast@kernel.org>
Cc: bpf@vger.kernel.org, tj@kernel.org, kernel-team@meta.com
Subject: Re: [PATCH dwarves v1 2/2] btf_encoder: implement KF_IMPLICIT_PROG_AUX_ARG kfunc flag handling
Date: Thu, 25 Sep 2025 06:28:26 -0700 [thread overview]
Message-ID: <b92d892f6a09fc7a411838ccf03dfebbba96384b.camel@gmail.com> (raw)
In-Reply-To: <a7f28918-7eda-42e9-ae41-446b7a2d9759@linux.dev>
On Wed, 2025-09-24 at 20:59 -0700, Ihor Solodrai wrote:
[...]
> I'm not sure how generic KF_IMPLICIT_ARG would even work.
> Any *implicit* parameter requires a very concrete implementation in
> the verifier: an actual pointer of a particular type is injected after
> the verification.
Does not seem complicated:
- In pahole generate a special decl_tag for bpftool.
- In bpftool, don't emit last argument to vmlinux.h, if that flag is present.
- on kernel side, when checking kfunc args, also check for the flag
and switch over types recorded for last function parameter in BTF.
If kernel knows how to handle it, great, if it does not, emit
verifier error.
- Not sure, but likely, the change on the libbpf side will be needed,
as it compares function prototypes between program and kernel BTFs.
E.g., for bpf_wq_set_callback keep the definition as is:
__bpf_kfunc int bpf_wq_set_callback(struct bpf_wq *wq,
int (callback_fn)(void *map, int *key, void *value),
unsigned int flags,
struct bpf_prog_aux *aux)
Kernel BTF will have it with full set of parameters.
But because of the flag, it will be printed w/o last parameter in
vmlinux.h:
extern int bpf_wq_set_callback(struct bpf_wq *wq,
int (callback_fn)(void *map, int *key, void *value),
unsigned int flags) __weak __ksym
On kernel side check_kfunc_args() will have access to complete BTF
declaration, so it can:
- check presence of the flag
- lookup bpf_prog_aux from the kernel side BTF
- call set_kfunc_arg_prog_regno.
> So we have to do a type check on pahole side to catch invalid kfunc
> declarations. And the verifier of course must be very strict about
> where it can pass pointers to kernel objects.
Type checks on pahole side will require upgrades to both kernel and
pahole, when new implicit parameter types are added. I'd try to avoid
that.
Also, do we plan to have several implicit parameters passed to a same
function?
next prev parent reply other threads:[~2025-09-25 13:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-24 21:15 [PATCH dwarves v1 0/2] btf_encoder: KF_IMPLICIT_PROG_AUX_ARG support Ihor Solodrai
2025-09-24 21:15 ` [PATCH dwarves v1 1/2] btf_encoder: refactor btf_encoder__add_func_proto Ihor Solodrai
2025-09-24 21:15 ` [PATCH dwarves v1 2/2] btf_encoder: implement KF_IMPLICIT_PROG_AUX_ARG kfunc flag handling Ihor Solodrai
2025-09-25 1:22 ` Eduard Zingerman
2025-09-25 3:59 ` Ihor Solodrai
2025-09-25 13:28 ` Eduard Zingerman [this message]
2025-09-25 17:15 ` 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=b92d892f6a09fc7a411838ccf03dfebbba96384b.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=acme@kernel.org \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=dwarves@vger.kernel.org \
--cc=ihor.solodrai@linux.dev \
--cc=kernel-team@meta.com \
--cc=tj@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