All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
To: Timur Chernykh <tim.cherry.co@gmail.com>, bpf@vger.kernel.org
Subject: Re: [PATCH 1/2] libbpf: add proto_func param name generation on sanitazing it to enum type
Date: Wed, 2 Apr 2025 13:41:52 +0100	[thread overview]
Message-ID: <635cc3eb-a7db-4647-accf-86a03436eeb9@gmail.com> (raw)
In-Reply-To: <20250331201016.345704-2-tim.cherry.co@gmail.com>

On 31/03/2025 21:09, Timur Chernykh wrote:
> Signed-off-by: Timur Chernykh <tim.cherry.co@gmail.com>
Thanks for submitting this patchset, do you mind adding a proper commit 
message for each commit in the set.
> ---
>   tools/lib/bpf/libbpf.c | 42 ++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 42 insertions(+)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 6b85060f07b3..8e1edba443dd 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -3128,6 +3128,8 @@ static int bpf_object__sanitize_btf(struct bpf_object *obj, struct btf *btf)
>   	bool has_type_tag = kernel_supports(obj, FEAT_BTF_TYPE_TAG);
>   	bool has_enum64 = kernel_supports(obj, FEAT_BTF_ENUM64);
>   	bool has_qmark_datasec = kernel_supports(obj, FEAT_BTF_QMARK_DATASEC);
> +
> +	char name_gen_buff[32] = {0};
>   	int enum64_placeholder_id = 0;
>   	struct btf_type *t;
>   	int i, j, vlen;
> @@ -3178,10 +3180,50 @@ static int bpf_object__sanitize_btf(struct bpf_object *obj, struct btf *btf)
>   			if (name[0] == '?')
>   				name[0] = '_';
>   		} else if (!has_func && btf_is_func_proto(t)) {
> +			struct btf_param* params;
`struct btf_param *params` here and in other places, put asterisk closer 
to var name, not type.
> +			int new_param_name_off;
Maybe just `new_name_off`, prefer shorter names, when possible.
> +
>   			/* replace FUNC_PROTO with ENUM */
>   			vlen = btf_vlen(t);
>   			t->info = BTF_INFO_ENC(BTF_KIND_ENUM, 0, vlen);
>   			t->size = sizeof(__u32); /* kernel enforced */
> +
> +			/* since the btf_enum and btf_param has the same binary layout it's ok to use btf_param */
> +			params = btf_params(t);
> +
> +			for (j = 0; j < vlen; ++j) {
> +				struct btf_param* param = &params[j];
> +				const char* param_name = btf__str_by_offset(btf, param->name_off);
> +
> +				/*
> +				 * kernel disallow any unnamed enum members which can be generated for,
> +				 * as example, struct members like
> +				 * struct quota_format_ops {
> +				 *     ...
> +				 *     int (*get_next_id)(struct super_block *, struct kqid *);
> +				 *     ...
> +				 * }
> +				 */
> +				if (param_name && param_name[0]) {
> +					/* definitely has a name, valid it or no should decide kernel verifier */
> +					continue;
> +				}
> +
> +				/*
> +				 * generate an uniq name for each func_proto
> +				 */
> +				snprintf(name_gen_buff, sizeof(name_gen_buff), "__parm_proto_%d_%d", i, j);
> +				new_param_name_off = btf__add_str(btf, name_gen_buff);
> +
> +				if (new_param_name_off < 0) {
> +					pr_warn("Error creating the name for func_proto param");
append \n to the error message.
> +					return new_param_name_off;
> +				}
> +
> +				/* give a valid name to func_proto param as it now an enum member */
> +				param->name_off = new_param_name_off;
> +			}
> +
>   		} else if (!has_func && btf_is_func(t)) {
>   			/* replace FUNC with TYPEDEF */
>   			t->info = BTF_INFO_ENC(BTF_KIND_TYPEDEF, 0, 0);



  reply	other threads:[~2025-04-02 12:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-31 20:09 Improvements of BTF sanitizing for old kernels Timur Chernykh
2025-03-31 20:09 ` [PATCH 1/2] libbpf: add proto_func param name generation on sanitazing it to enum type Timur Chernykh
2025-04-02 12:41   ` Mykyta Yatsenko [this message]
2025-03-31 20:09 ` [PATCH 2/2] libbpf: add check if kernel supports kind flag and fix the bitfield members in union and structs if not Timur Chernykh
2025-04-02 13:05   ` Mykyta Yatsenko

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=635cc3eb-a7db-4647-accf-86a03436eeb9@gmail.com \
    --to=mykyta.yatsenko5@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=tim.cherry.co@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 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.