All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ihor Solodrai <ihor.solodrai@linux.dev>
To: Eduard Zingerman <eddyz87@gmail.com>,
	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: Wed, 24 Sep 2025 20:59:28 -0700	[thread overview]
Message-ID: <a7f28918-7eda-42e9-ae41-446b7a2d9759@linux.dev> (raw)
In-Reply-To: <4fb8a812fdd01f115a99317c8e46ad055b5bf102.camel@gmail.com>



On 9/24/25 6:22 PM, Eduard Zingerman wrote:
> On Wed, 2025-09-24 at 14:15 -0700, Ihor Solodrai wrote:
>> When a kfunc is marked with KF_IMPLICIT_PROG_AUX_ARG, do not emit the
>> last parameter of this function to BTF.
> 
> [...]
> 
>> @@ -887,6 +923,12 @@ static int32_t btf_encoder__add_func_proto_for_state(struct btf_encoder *encoder
>>  	nr_params = state->nr_parms;
>>  	type_id = state->ret_type_id;
>>  
>> +	if (is_kfunc_state(state) && KF_IMPLICIT_PROG_AUX_ARG & state->elf->kfunc_flags) {
>> +		if (validate_kfunc_with_implicit_prog_aux_arg(state))
>> +			return -1;
>> +		nr_params--;
>> +	}
>> +
>>  	id = btf_encoder__emit_func_proto(encoder, type_id, nr_params);
>>  	if (id < 0)
>>  		return id;
> 
> This change hides the fact that function accepts one more parameter
> both from kernel BTF and from program BTF (via vmlinux.h).

Right, this is intentional.

> Do we anticipate other implicit parameter types?

It's very plausible, but I don't know of specific examples.

> Because if we do, it seems like having some generic KF_IMPLICIT_ARG
> and hiding it only from vmlinux.h seem more flexible.

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. 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.

From a couple of discussions with Andrii, my impression is that it
would be beneficial to have some kind of generic "execution context"
available to BPF programs and/or kfuncs to cover all potential
implicit arguments. But that's a separate big discussion.

Supporting bpf_prog_aux specifically is a pragmatic improvement to the
current inconvenience that sched_ext has to deal with [1].

[1] https://lore.kernel.org/bpf/20250920005931.2753828-42-tj@kernel.org/


  reply	other threads:[~2025-09-25  3:59 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 [this message]
2025-09-25 13:28       ` Eduard Zingerman
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=a7f28918-7eda-42e9-ae41-446b7a2d9759@linux.dev \
    --to=ihor.solodrai@linux.dev \
    --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=eddyz87@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.