All of lore.kernel.org
 help / color / mirror / Atom feed
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, drosen@google.com
Subject: Re: [PATCH bpf-next v8 03/10] bpf: add struct_ops_tab to btf.
Date: Mon, 30 Oct 2023 18:09:29 -0700	[thread overview]
Message-ID: <736a8485-c9c0-fd75-6e8b-3207df8dda6a@linux.dev> (raw)
In-Reply-To: <20231030192810.382942-4-thinker.li@gmail.com>

On 10/30/23 12:28 PM, thinker.li@gmail.com wrote:
> From: Kui-Feng Lee <thinker.li@gmail.com>
> 
> Maintain a registry of registered struct_ops types in the per-btf (module)
> struct_ops_tab. This registry allows for easy lookup of struct_ops types
> that are registered by a specific module.
> 
> Every struct_ops type should have an associated module BTF to provide type
> information since we are going to allow modules to define and register new
> struct_ops types. Once this change is made, the bpf_struct_ops subsystem
> knows where to look up type info with just a bpf_struct_ops.

I think this part needs better description. I found it hard to parse. In particular:

...
   the "bpf_struct_ops" subsystem
        knows where to look up type info with just
     a "bpf_struct_ops"
...

May be something like:

It is a preparation work for supporting kernel module struct_ops in a latter 
patch. Each struct_ops will be registered under its own kernel module btf and 
will be stored in the newly added btf->struct_ops_tab. The bpf verifier and bpf 
syscall (e.g. prog and map cmd) can find the struct_ops and its btf 
type/size/id... information from btf->struct_ops_tab.

> 
> The subsystem looks up struct_ops types from a given module BTF although it
> is always btf_vmlinux now. Once start using struct_ops_tab, btfs other than
> btf_vmlinux can be used as well.

I think this describes about the "struct btf *btf" argument change in this 
patch. This seems unrelated to the "add struct_ops_tab to btf" change. Can it be 
in its own preparation patch?

[ ... ]

> diff --git a/kernel/bpf/bpf_struct_ops.c b/kernel/bpf/bpf_struct_ops.c
> index e35d6321a2f8..0bc21a39257d 100644
> --- a/kernel/bpf/bpf_struct_ops.c
> +++ b/kernel/bpf/bpf_struct_ops.c
> @@ -186,6 +186,7 @@ static void bpf_struct_ops_init_one(struct bpf_struct_ops_desc *st_ops_desc,
>   			pr_warn("Error in init bpf_struct_ops %s\n",
>   				st_ops->name);
>   		} else {
> +			st_ops_desc->btf = btf;
>   			st_ops_desc->type_id = type_id;
>   			st_ops_desc->type = t;
>   			st_ops_desc->value_id = value_id;
> @@ -222,7 +223,7 @@ void bpf_struct_ops_init(struct btf *btf, struct bpf_verifier_log *log)
>   extern struct btf *btf_vmlinux;
>   
>   static const struct bpf_struct_ops_desc *
> -bpf_struct_ops_find_value(u32 value_id)
> +bpf_struct_ops_find_value(struct btf *btf, u32 value_id)

The "!btf_vmlinux" check a few lines below should also be changed to "!btf". I 
think I had commented on a similar point in v5.

>   {
>   	unsigned int i;
>   
> @@ -237,7 +238,8 @@ bpf_struct_ops_find_value(u32 value_id)
>   	return NULL;
>   }
>   
> -const struct bpf_struct_ops_desc *bpf_struct_ops_find(u32 type_id)
> +const struct bpf_struct_ops_desc *
> +bpf_struct_ops_find(struct btf *btf, u32 type_id)

same here.

>   {
>   	unsigned int i;
>   

[ ... ]

> +static struct bpf_struct_ops_desc *
> +btf_add_struct_ops(struct btf *btf, struct bpf_struct_ops *st_ops)
> +{
> +	struct btf_struct_ops_tab *tab, *new_tab;
> +	int i;
> +
> +	if (!btf)
> +		return ERR_PTR(-ENOENT);
> +
> +	/* Assume this function is called for a module when the module is
> +	 * loading.
> +	 */
> +
> +	tab = btf->struct_ops_tab;
> +	if (!tab) {
> +		tab = kzalloc(offsetof(struct btf_struct_ops_tab, ops[4]),
> +			      GFP_KERNEL);
> +		if (!tab)
> +			return ERR_PTR(-ENOMEM);
> +		tab->capacity = 4;
> +		btf->struct_ops_tab = tab;
> +	}
> +
> +	for (i = 0; i < tab->cnt; i++)
> +		if (tab->ops[i].st_ops == st_ops)
> +			return ERR_PTR(-EEXIST);
> +
> +	if (tab->cnt == tab->capacity) {
> +		new_tab = krealloc(tab, sizeof(*tab) +
> +				   sizeof(struct bpf_struct_ops *) *
> +				   tab->capacity * 2, GFP_KERNEL);

nit. Use a similar offsetof() like a few lines above.

> +		if (!new_tab)
> +			return ERR_PTR(-ENOMEM);
> +		tab = new_tab;
> +		tab->capacity *= 2;
> +		btf->struct_ops_tab = tab;
> +	}
> +
> +	btf->struct_ops_tab->ops[btf->struct_ops_tab->cnt].st_ops = st_ops;

nit. s/btf->struct_ops_tab/tab/

> +
> +	return &btf->struct_ops_tab->ops[btf->struct_ops_tab->cnt++];
> +}


  reply	other threads:[~2023-10-31  1:09 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-30 19:28 [PATCH bpf-next v8 00/10] Registrating struct_ops types from modules thinker.li
2023-10-30 19:28 ` [PATCH bpf-next v8 01/10] bpf: refactory struct_ops type initialization to a function thinker.li
2023-10-30 19:28 ` [PATCH bpf-next v8 02/10] bpf, net: introduce bpf_struct_ops_desc thinker.li
2023-10-31  6:40   ` Martin KaFai Lau
2023-10-31 16:00     ` Kui-Feng Lee
2023-10-30 19:28 ` [PATCH bpf-next v8 03/10] bpf: add struct_ops_tab to btf thinker.li
2023-10-31  1:09   ` Martin KaFai Lau [this message]
2023-10-31 16:57     ` Kui-Feng Lee
2023-10-30 19:28 ` [PATCH bpf-next v8 04/10] bpf: hold module for bpf_struct_ops_map thinker.li
2023-10-31  1:21   ` Martin KaFai Lau
2023-10-31 17:46     ` Kui-Feng Lee
2023-10-30 19:28 ` [PATCH bpf-next v8 05/10] bpf: validate value_type thinker.li
2023-10-30 19:28 ` [PATCH bpf-next v8 06/10] bpf: pass attached BTF to the bpf_struct_ops subsystem thinker.li
2023-10-31  1:53   ` Martin KaFai Lau
2023-10-31 20:31     ` Kui-Feng Lee
2023-10-30 19:28 ` [PATCH bpf-next v8 07/10] bpf, net: switch to dynamic registration thinker.li
2023-10-31  6:36   ` Martin KaFai Lau
2023-10-31 23:34     ` Kui-Feng Lee
2023-11-01  0:02       ` Martin KaFai Lau
2023-11-01  0:19         ` Kui-Feng Lee
2023-11-01  0:19         ` Kui-Feng Lee
2023-11-02  0:17           ` Martin KaFai Lau
2023-11-02  0:59             ` Kui-Feng Lee
2023-11-02  1:32               ` Martin KaFai Lau
2023-11-02  4:19                 ` Kui-Feng Lee
2023-10-30 19:28 ` [PATCH bpf-next v8 08/10] libbpf: Find correct module BTFs for struct_ops maps and progs thinker.li
2023-10-30 19:28 ` [PATCH bpf-next v8 09/10] bpf: export btf_ctx_access to modules thinker.li
2023-10-30 19:28 ` [PATCH bpf-next v8 10/10] selftests/bpf: test case for register_bpf_struct_ops() thinker.li
2023-10-31  6:59   ` Martin KaFai Lau
2023-11-01  0:30     ` Kui-Feng Lee
2023-11-02  1:43       ` Martin KaFai Lau
2023-11-02 18:26         ` Kui-Feng Lee
2023-10-31 20:45 ` [PATCH bpf-next v8 00/10] Registrating struct_ops types from modules Martin KaFai Lau
2023-11-01  0:48   ` Kui-Feng Lee

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=736a8485-c9c0-fd75-6e8b-3207df8dda6a@linux.dev \
    --to=martin.lau@linux.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=drosen@google.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 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.