All of lore.kernel.org
 help / color / mirror / Atom feed
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:16:14 -0700	[thread overview]
Message-ID: <5a78f3cc-883a-4d37-b455-15e74684e8cf@linux.dev> (raw)
In-Reply-To: <CAEf4BzZXyq8Y85v6UQo+xZZCyxSndsnHpPQnxfR-_FOfVqMseg@mail.gmail.com>


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.


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

  parent reply	other threads:[~2024-08-15 22:16 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 [this message]
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=5a78f3cc-883a-4d37-b455-15e74684e8cf@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.