From: Yonghong Song <yonghong.song@linux.dev>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Eduard Zingerman <eddyz87@gmail.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, 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: Thu, 15 Aug 2024 15:22:09 -0700 [thread overview]
Message-ID: <97f77f76-e754-4346-8e11-af00be6224cb@linux.dev> (raw)
In-Reply-To: <5a78f3cc-883a-4d37-b455-15e74684e8cf@linux.dev>
On 8/15/24 3:16 PM, Yonghong Song wrote:
>
> On 8/15/24 2:24 PM, Andrii Nakryiko wrote:
>> On Mon, Aug 12, 2024 at 4:44 PM Eduard Zingerman <eddyz87@gmail.com>
>> 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;
>>>
>>> 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;
>>> +
>>> + 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);
>> Somewhere deep in btf_dump implementation of libbpf, there is a
>> special handling of `<whatever> func(void)` (no args) function as
>> having vlen == 1 and type being VOID (i.e., zero). I don't know if
>> that still can happen, but I believe at some point we could get this
>> vlen==1 and type=VOID for no-args functions. So I wonder if we should
>> handle that here as well, or is it some compiler atavism we can forget
>> about?
>
> The case to have vlen=1 and type=VOID only happens for
> bpf programs with llvm19 and later.
> For example,
>
> $ cat t.c
> int foo(); // a kfunc or a helper
> int bar() {
> return foo(1, 2);
> }
>
> $ clang --target=bpf -O2 -g -c t.c && llvm-dwarfdump t.o
> t.c:3:13: warning: passing arguments to 'foo' without a prototype is
> deprecated in all versions of C and is not supported in C23
> [-Wdeprecated-non-prototype]
> 3 | return foo(1, 2);
> | ^
> 1 warning generated.
> t.o: file format elf64-bpf
> ...
> 0x00000039: DW_TAG_subprogram
> DW_AT_name ("foo")
> DW_AT_decl_file ("/home/yhs/t.c")
> DW_AT_decl_line (1)
> DW_AT_type (0x00000043 "int")
> DW_AT_declaration (true)
> DW_AT_external (true)
>
> 0x00000041: DW_TAG_unspecified_parameters
>
> 0x00000042: NULL
> ...
>
> If we do see a BPF kfunc/helper with vlen=1 and type is VOID,
> that means the number of arguments is actual UNKNOWN
> based on dwarf DW_TAG_subprogram tag. Although it is unlikely
> people to write code like above, it might be still useful
> to add check with vlen=1 and type=VOID and reject such a case.
For vmlinux BTF, this is not possible since eventually all function
has a definition which will define the function precisely w.r.t.
the number of arguments and their types.
>
>
>>
>>> + 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);
>>> + }
>>> +
>>> if (clobbered_regs_mask == ALL_CALLER_SAVED_REGS)
>>> return;
>>>
>>> --
>>> 2.45.2
>>>
next prev parent reply other threads:[~2024-08-15 22:22 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
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 [this message]
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=97f77f76-e754-4346-8e11-af00be6224cb@linux.dev \
--to=yonghong.song@linux.dev \
--cc=andrii.nakryiko@gmail.com \
--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 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.