BPF List
 help / color / mirror / Atom feed
From: Kui-Feng Lee <sinquersw@gmail.com>
To: Martin KaFai Lau <martin.lau@linux.dev>, thinker.li@gmail.com
Cc: kuifeng@meta.com, bpf@vger.kernel.org, ast@kernel.org,
	song@kernel.org, kernel-team@meta.com, andrii@kernel.org,
	davemarchevsky@meta.com, dvernet@meta.com
Subject: Re: [PATCH bpf-next v8 3/4] bpf: Create argument information for nullable arguments.
Date: Mon, 12 Feb 2024 09:09:47 -0800	[thread overview]
Message-ID: <47ef712a-45fd-45d1-b494-7e435a7d0f8d@gmail.com> (raw)
In-Reply-To: <9404a412-90ca-4a45-92f2-a034f99c66f9@linux.dev>



On 2/11/24 11:49, Martin KaFai Lau wrote:
> On 2/8/24 6:37 PM, thinker.li@gmail.com wrote:
>> +/* Prepare argument info for every nullable argument of a member of a
>> + * struct_ops type.
>> + *
>> + * Initialize a struct bpf_struct_ops_arg_info according to type info of
>> + * the arguments of a stub function. (Check kCFI for more information 
>> about
>> + * stub functions.)
>> + *
>> + * Each member in the struct_ops type has a struct 
>> bpf_struct_ops_arg_info
>> + * to provide an array of struct bpf_ctx_arg_aux, which in turn provides
>> + * the information that used by the verifier to check the arguments 
>> of the
>> + * BPF struct_ops program assigned to the member. Here, we only care 
>> about
>> + * the arguments that are marked as __nullable.
>> + *
>> + * The array of struct bpf_ctx_arg_aux is eventually assigned to
>> + * prog->aux->ctx_arg_info of BPF struct_ops programs and passed to the
>> + * verifier. (See check_struct_ops_btf_id())
>> + *
>> + * arg_info->info will be the list of struct bpf_ctx_arg_aux if 
>> success. If
>> + * fails, it will be kept untouched.
>> + */
>> +static int prepare_arg_info(struct btf *btf,
>> +                const char *st_ops_name,
>> +                const char *member_name,
>> +                const struct btf_type *func_proto,
>> +                struct bpf_struct_ops_arg_info *arg_info)
>> +{
>> +    const struct btf_type *stub_func_proto, *pointed_type;
>> +    const struct btf_param *stub_args, *args;
>> +    struct bpf_ctx_arg_aux *info, *info_buf;
>> +    u32 nargs, arg_no, info_cnt = 0;
>> +    s32 arg_btf_id;
>> +    int offset;
>> +
>> +    stub_func_proto = find_stub_func_proto(btf, st_ops_name, 
>> member_name);
>> +    if (!stub_func_proto)
>> +        return 0;
>> +
>> +    /* Check if the number of arguments of the stub function is the same
>> +     * as the number of arguments of the function pointer.
>> +     */
>> +    nargs = btf_type_vlen(func_proto);
>> +    if (nargs != btf_type_vlen(stub_func_proto)) {
>> +        pr_warn("the number of arguments of the stub function %s__%s 
>> does not match the number of arguments of the member %s of struct %s\n",
>> +            st_ops_name, member_name, member_name, st_ops_name);
>> +        return -EINVAL;
>> +    }
>> +
>> +    args = btf_params(func_proto);
>> +    stub_args = btf_params(stub_func_proto);
>> +
>> +    info_buf = kcalloc(nargs, sizeof(*info_buf), GFP_KERNEL);
>> +    if (!info_buf)
>> +        return -ENOMEM;
>> +
>> +    /* Prepare info for every nullable argument */
>> +    info = info_buf;
>> +    for (arg_no = 0; arg_no < nargs; arg_no++) {
>> +        /* Skip arguments that is not suffixed with
>> +         * "__nullable".
>> +         */
>> +        if (!btf_param_match_suffix(btf, &stub_args[arg_no],
>> +                        MAYBE_NULL_SUFFIX))
>> +            continue;
>> +
>> +        /* Should be a pointer to struct */
>> +        pointed_type = btf_type_resolve_ptr(btf,
>> +                            args[arg_no].type,
>> +                            &arg_btf_id);
>> +        if (!pointed_type ||
>> +            !btf_type_is_struct(pointed_type)) {
>> +            pr_warn("stub function %s__%s has %s tagging to an 
>> unsupported type\n",
>> +                st_ops_name, member_name, MAYBE_NULL_SUFFIX);
>> +            goto err_out;
>> +        }
> 
> We briefly talked about this and compiler can probably catch any arg
> type inconsistency between the stub func_proto and the original func_proto.
> 
> I still think it is better to be strict at the
> beginning and ensure the "stub_args" type is the same as the original 
> "args"
> type. It is to bar any type inconsistency going forward on the __nullable
> tagged argument (e.g. changing the original func_proto but forgot to
> change the stub func_proto).
> 
> We can revisit in the future if the following type comparison does not 
> work well.
> 
>                  if (args[arg_no].type != stub_args[arg_no].type) {
>              pr_warn("arg#%u type in stub func_proto %s__%s does not 
> match with its original func_proto\n",
>                  arg_no, st_ops_name, member_name);
>              goto err_out;
>                  }


Agree!

> 
>> +
>> +        offset = btf_ctx_arg_offset(btf, func_proto, arg_no);
>> +        if (offset < 0) {
>> +            pr_warn("stub function %s__%s has an invalid trampoline 
>> ctx offset for arg#%u\n",
>> +                st_ops_name, member_name, arg_no);
>> +            goto err_out;
>> +        }
>> +
>> +        /* Fill the information of the new argument */
>> +        info->reg_type =
>> +            PTR_TRUSTED | PTR_TO_BTF_ID | PTR_MAYBE_NULL;
>> +        info->btf_id = arg_btf_id;
>> +        info->btf = btf;
>> +        info->offset = offset;
>> +
>> +        info++;
>> +        info_cnt++;
>> +    }
>> +
>> +    if (info_cnt) {
>> +        arg_info->info = info_buf;
>> +        arg_info->cnt = info_cnt;
>> +    } else {
>> +        kfree(info_buf);
>> +    }
>> +
>> +    return 0;
>> +
>> +err_out:
>> +    kfree(info_buf);
>> +
>> +    return -EINVAL;
>> +}
>> +
>> +/* Clean up the arg_info in a struct bpf_struct_ops_desc. */
>> +void bpf_struct_ops_desc_release(struct bpf_struct_ops_desc 
>> *st_ops_desc)
>> +{
>> +    struct bpf_struct_ops_arg_info *arg_info;
>> +    int i;
>> +
>> +    arg_info = st_ops_desc->arg_info;
>> +    if (!arg_info)
> 
> nit. I think this check is unnecessary ?
> 
> If the above two comments make sense to you, I can make the adjustment. 
> No need to resend.


Agree!

> 
> Patch 4 lgtm.
> 
>> +        return;
>> +
>> +    for (i = 0; i < btf_type_vlen(st_ops_desc->type); i++)
>> +        kfree(arg_info[i].info);
>> +
>> +    kfree(arg_info);
>> +}
>> +
> 

  reply	other threads:[~2024-02-12 17:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-09  2:37 [PATCH bpf-next v8 0/4] Support PTR_MAYBE_NULL for struct_ops arguments thinker.li
2024-02-09  2:37 ` [PATCH bpf-next v8 1/4] bpf: add btf pointer to struct bpf_ctx_arg_aux thinker.li
2024-02-11 18:59   ` Martin KaFai Lau
2024-02-09  2:37 ` [PATCH bpf-next v8 2/4] bpf: Move __kfunc_param_match_suffix() to btf.c thinker.li
2024-02-09  2:37 ` [PATCH bpf-next v8 3/4] bpf: Create argument information for nullable arguments thinker.li
2024-02-11 19:49   ` Martin KaFai Lau
2024-02-12 17:09     ` Kui-Feng Lee [this message]
2024-02-12 11:45   ` Jiri Olsa
2024-02-12 17:50     ` Kui-Feng Lee
2024-02-13 23:27     ` Martin KaFai Lau
2024-02-09  2:37 ` [PATCH bpf-next v8 4/4] selftests/bpf: Test PTR_MAYBE_NULL arguments of struct_ops operators thinker.li
2024-02-13 23:30 ` [PATCH bpf-next v8 0/4] Support PTR_MAYBE_NULL for struct_ops arguments patchwork-bot+netdevbpf

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=47ef712a-45fd-45d1-b494-7e435a7d0f8d@gmail.com \
    --to=sinquersw@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=davemarchevsky@meta.com \
    --cc=dvernet@meta.com \
    --cc=kernel-team@meta.com \
    --cc=kuifeng@meta.com \
    --cc=martin.lau@linux.dev \
    --cc=song@kernel.org \
    --cc=thinker.li@gmail.com \
    /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