From: Martin KaFai Lau <martin.lau@linux.dev>
To: thinker.li@gmail.com
Cc: sinquersw@gmail.com, 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: Sun, 11 Feb 2024 11:49:32 -0800 [thread overview]
Message-ID: <9404a412-90ca-4a45-92f2-a034f99c66f9@linux.dev> (raw)
In-Reply-To: <20240209023750.1153905-4-thinker.li@gmail.com>
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;
}
> +
> + 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.
Patch 4 lgtm.
> + return;
> +
> + for (i = 0; i < btf_type_vlen(st_ops_desc->type); i++)
> + kfree(arg_info[i].info);
> +
> + kfree(arg_info);
> +}
> +
next prev parent reply other threads:[~2024-02-11 19:49 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 [this message]
2024-02-12 17:09 ` Kui-Feng Lee
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=9404a412-90ca-4a45-92f2-a034f99c66f9@linux.dev \
--to=martin.lau@linux.dev \
--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=sinquersw@gmail.com \
--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