From: Yonghong Song <yonghong.song@linux.dev>
To: Eduard Zingerman <eddyz87@gmail.com>,
bpf@vger.kernel.org, ast@kernel.org
Cc: andrii@kernel.org, daniel@iogearbox.net, martin.lau@linux.dev,
kernel-team@fb.com
Subject: Re: [PATCH bpf-next 1/3] bpf: support nocsr patterns for calls to kfuncs
Date: Mon, 12 Aug 2024 22:36:13 -0700 [thread overview]
Message-ID: <2ca49adc-2c90-42ee-b1ff-bf339731ad5a@linux.dev> (raw)
In-Reply-To: <20240812234356.2089263-2-eddyz87@gmail.com>
On 8/12/24 4:43 PM, Eduard Zingerman wrote:
> Recognize nocsr patterns around kfunc calls.
> For example, suppose bpf_cast_to_kern_ctx() follows nocsr contract
> (which it does, it is rewritten by verifier as "r0 = r1" insn),
> in such a case, rewrite BPF program below:
>
> r2 = 1;
> *(u64 *)(r10 - 32) = r2;
> call %[bpf_cast_to_kern_ctx];
> r2 = *(u64 *)(r10 - 32);
> r0 = r2;
>
> Removing the spill/fill pair:
>
> r2 = 1;
> call %[bpf_cast_to_kern_ctx];
> r0 = r2;
I can see this indeed a good optimization esp. when there is a register
pressure for the program, and like above r2 has to be spilled.
Using nocsr for bpf_cast_to_kern_ctx() can remove those spill/fill
insns.
>
> Add a KF_NOCSR flag to mark kfuncs that follow nocsr contract.
>
> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
> ---
> include/linux/btf.h | 1 +
> kernel/bpf/verifier.c | 36 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 37 insertions(+)
>
> diff --git a/include/linux/btf.h b/include/linux/btf.h
> index cffb43133c68..59ca37300423 100644
> --- a/include/linux/btf.h
> +++ b/include/linux/btf.h
> @@ -75,6 +75,7 @@
> #define KF_ITER_NEXT (1 << 9) /* kfunc implements BPF iter next method */
> #define KF_ITER_DESTROY (1 << 10) /* kfunc implements BPF iter destructor */
> #define KF_RCU_PROTECTED (1 << 11) /* kfunc should be protected by rcu cs when they are invoked */
> +#define KF_NOCSR (1 << 12) /* kfunc follows nocsr calling contract */
>
> /*
> * Tag marking a kernel function as a kfunc. This is meant to minimize the
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index df3be12096cf..c579f74be3f9 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -16140,6 +16140,28 @@ static bool verifier_inlines_helper_call(struct bpf_verifier_env *env, s32 imm)
> }
> }
>
> +/* Same as helper_nocsr_clobber_mask() but for kfuncs, see comment above */
> +static u32 kfunc_nocsr_clobber_mask(struct bpf_kfunc_call_arg_meta *meta)
> +{
> + const struct btf_param *params;
> + u32 vlen, i, mask;
In helper_nocsr_clobber_mask, we have u8 mask. To be consistent, can we have 'u8 mask' here?
Are you worried that the number of arguments could be more than 7? This seems not the case
right now.
> +
> + params = btf_params(meta->func_proto);
> + vlen = btf_type_vlen(meta->func_proto);
> + mask = 0;
> + if (!btf_type_is_void(btf_type_by_id(meta->btf, meta->func_proto->type)))
> + mask |= BIT(BPF_REG_0);
> + for (i = 0; i < vlen; ++i)
> + mask |= BIT(BPF_REG_1 + i);
> + return mask;
> +}
> +
> +/* Same as verifier_inlines_helper_call() but for kfuncs, see comment above */
> +static bool verifier_inlines_kfunc_call(struct bpf_kfunc_call_arg_meta *meta)
> +{
> + return false;
> +}
> +
> /* GCC and LLVM define a no_caller_saved_registers function attribute.
> * This attribute means that function scratches only some of
> * the caller saved registers defined by ABI.
> @@ -16238,6 +16260,20 @@ static void mark_nocsr_pattern_for_call(struct bpf_verifier_env *env,
> bpf_jit_inlines_helper_call(call->imm));
> }
>
> + if (bpf_pseudo_kfunc_call(call)) {
> + struct bpf_kfunc_call_arg_meta meta;
> + int err;
> +
> + err = fetch_kfunc_meta(env, call, &meta, NULL);
> + if (err < 0)
> + /* error would be reported later */
> + return;
> +
> + clobbered_regs_mask = kfunc_nocsr_clobber_mask(&meta);
> + can_be_inlined = (meta.kfunc_flags & KF_NOCSR) &&
> + verifier_inlines_kfunc_call(&meta);
I think we do not need both meta.kfunc_flags & KF_NOCSR and
verifier_inlines_kfunc_call(&meta). Only one of them is enough
since they test very similar thing. You do need to ensure
kfuncs with KF_NOCSR in special_kfunc_list though.
WDYT?
> + }
> +
> if (clobbered_regs_mask == ALL_CALLER_SAVED_REGS)
> return;
>
next prev parent reply other threads:[~2024-08-13 5:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-12 23:43 [PATCH bpf-next 0/3] support nocsr patterns for calls to kfuncs Eduard Zingerman
2024-08-12 23:43 ` [PATCH bpf-next 1/3] bpf: " Eduard Zingerman
2024-08-13 5:36 ` Yonghong Song [this message]
2024-08-13 7:55 ` Eduard Zingerman
2024-08-13 15:18 ` Yonghong Song
2024-08-13 18:57 ` Eduard Zingerman
2024-08-15 21:24 ` Andrii Nakryiko
2024-08-15 22:07 ` Eduard Zingerman
2024-08-15 22:23 ` Yonghong Song
2024-08-15 22:29 ` Eduard Zingerman
2024-08-15 22:16 ` Yonghong Song
2024-08-15 22:22 ` Yonghong Song
2024-08-12 23:43 ` [PATCH bpf-next 2/3] bpf: mark bpf_cast_to_kern_ctx and bpf_rdonly_cast as KF_NOCSR Eduard Zingerman
2024-08-15 21:25 ` Andrii Nakryiko
2024-08-15 21:59 ` Eduard Zingerman
2024-08-15 22:12 ` Andrii Nakryiko
2024-08-15 22:14 ` Eduard Zingerman
2024-08-12 23:43 ` [PATCH bpf-next 3/3] selftests/bpf: check if nocsr pattern is recognized for kfuncs 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=2ca49adc-2c90-42ee-b1ff-bf339731ad5a@linux.dev \
--to=yonghong.song@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@fb.com \
--cc=martin.lau@linux.dev \
/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