From: Eduard Zingerman <eddyz87@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>, bpf@vger.kernel.org
Cc: kkd@meta.com, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@kernel.org>,
kernel-team@fb.com
Subject: Re: [PATCH bpf-next v1 1/7] bpf: Refactor and rename resource management
Date: Thu, 21 Nov 2024 08:57:32 -0800 [thread overview]
Message-ID: <4be3db522e31ea88119751d4e2d64a9e90397f6c.camel@gmail.com> (raw)
In-Reply-To: <20241121005329.408873-2-memxor@gmail.com>
On Wed, 2024-11-20 at 16:53 -0800, Kumar Kartikeya Dwivedi wrote:
> With the commit f6b9a69a9e56 ("bpf: Refactor active lock management"),
> we have begun using the acquired_refs array to also store active lock
> metadata, as a way to consolidate and manage all kernel resources that
> the program may acquire.
>
> This is beginning to cause some confusion and duplication in existing
> code, where the terms references now both mean lock reference state and
> the references for acquired kernel object pointers. To clarify and
> improve the current state of affairs, as well as reduce code duplication,
> make the following changes:
>
> Rename bpf_reference_state to bpf_resource_state, and begin using
> resource as the umbrella term. This terminology matches what we use in
> check_resource_leak. Next, "reference" now only means RES_TYPE_PTR, and
> the usage and meaning is updated accordingly.
>
> Next, factor out common code paths for managing addition and removal of
> resource state in acquire_resource_state and erase_resource_state, and
> then implement type specific resource handling on top of these common
> functions. Overall, this patch improves upon the confusion and minimizes
> code duplication, as we prepare to introduce new resource types in
> subsequent patches.
>
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> ---
Tbh, I like the old name a bit more.
The patch itself looks good.
Reviewed-by: Eduard Zingerman <eddyz87@gmail.com>
[...]
> @@ -1342,6 +1342,25 @@ static int grow_stack_state(struct bpf_verifier_env *env, struct bpf_func_state
> return 0;
> }
>
> +static struct bpf_resource_state *acquire_resource_state(struct bpf_verifier_env *env, int insn_idx, int *id)
Nit: there is no need to pass `int *id`, as it is available as (returned)->id.
> +{
> + struct bpf_func_state *state = cur_func(env);
> + int new_ofs = state->acquired_res;
> + struct bpf_resource_state *s;
> + int err;
> +
> + err = resize_resource_state(state, state->acquired_res + 1);
> + if (err)
> + return NULL;
> + s = &state->res[new_ofs];
> + s->type = RES_TYPE_INV;
> + if (id)
> + *id = s->id = ++env->id_gen;
> + s->insn_idx = insn_idx;
> +
> + return s;
> +}
> +
> /* Acquire a pointer id from the env and update the state->refs to include
> * this new pointer reference.
> * On success, returns a valid pointer id to associate with the register
[...]
> @@ -1349,55 +1368,52 @@ static int grow_stack_state(struct bpf_verifier_env *env, struct bpf_func_state
[...]
> -/* release function corresponding to acquire_reference_state(). Idempotent. */
> +static void erase_resource_state(struct bpf_func_state *state, int res_idx)
Nit: why not "release_..." to be consistent with the rest of the functions?
> +{
> + int last_idx = state->acquired_res - 1;
> +
> + if (last_idx && res_idx != last_idx)
> + memcpy(&state->res[res_idx], &state->res[last_idx], sizeof(*state->res));
> + memset(&state->res[last_idx], 0, sizeof(*state->res));
> + state->acquired_res--;
> +}
> +
> static int release_reference_state(struct bpf_func_state *state, int ptr_id)
> {
> - int i, last_idx;
> + int i;
>
> - last_idx = state->acquired_refs - 1;
> - for (i = 0; i < state->acquired_refs; i++) {
> - if (state->refs[i].type != REF_TYPE_PTR)
> + for (i = 0; i < state->acquired_res; i++) {
> + if (state->res[i].type != RES_TYPE_PTR)
> continue;
> - if (state->refs[i].id == ptr_id) {
> - if (last_idx && i != last_idx)
> - memcpy(&state->refs[i], &state->refs[last_idx],
> - sizeof(*state->refs));
> - memset(&state->refs[last_idx], 0, sizeof(*state->refs));
> - state->acquired_refs--;
> + if (state->res[i].id == ptr_id) {
> + erase_resource_state(state, i);
> return 0;
> }
> }
[...]
next prev parent reply other threads:[~2024-11-21 16:57 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-21 0:53 [PATCH bpf-next v1 0/7] IRQ save/restore Kumar Kartikeya Dwivedi
2024-11-21 0:53 ` [PATCH bpf-next v1 1/7] bpf: Refactor and rename resource management Kumar Kartikeya Dwivedi
2024-11-21 16:57 ` Eduard Zingerman [this message]
2024-11-21 17:17 ` Kumar Kartikeya Dwivedi
2024-11-22 0:24 ` Alexei Starovoitov
2024-11-22 0:31 ` Kumar Kartikeya Dwivedi
2024-11-21 0:53 ` [PATCH bpf-next v1 2/7] bpf: Be consistent between {acquire,find,release}_lock_state Kumar Kartikeya Dwivedi
2024-11-21 17:54 ` Eduard Zingerman
2024-11-21 0:53 ` [PATCH bpf-next v1 3/7] bpf: Consolidate RCU and preempt locks in bpf_func_state Kumar Kartikeya Dwivedi
2024-11-21 18:09 ` Eduard Zingerman
2024-11-21 18:12 ` Kumar Kartikeya Dwivedi
2024-11-21 18:54 ` Eduard Zingerman
2024-11-21 22:04 ` Kumar Kartikeya Dwivedi
2024-11-21 0:53 ` [PATCH bpf-next v1 4/7] bpf: Refactor mark_{dynptr,iter}_read Kumar Kartikeya Dwivedi
2024-11-21 18:00 ` Eduard Zingerman
2024-11-21 0:53 ` [PATCH bpf-next v1 5/7] bpf: Introduce support for bpf_local_irq_{save,restore} Kumar Kartikeya Dwivedi
2024-11-21 20:21 ` Eduard Zingerman
2024-11-21 22:06 ` Kumar Kartikeya Dwivedi
2024-11-21 23:08 ` Eduard Zingerman
2024-11-21 23:12 ` Kumar Kartikeya Dwivedi
2024-11-22 0:30 ` Eduard Zingerman
2024-11-22 0:32 ` Alexei Starovoitov
2024-11-22 0:42 ` Kumar Kartikeya Dwivedi
2024-11-21 22:46 ` kernel test robot
2024-11-21 0:53 ` [PATCH bpf-next v1 6/7] selftests/bpf: Expand coverage of preempt tests to sleepable kfunc Kumar Kartikeya Dwivedi
2024-11-21 20:23 ` Eduard Zingerman
2024-11-21 0:53 ` [PATCH bpf-next v1 7/7] selftests/bpf: Add IRQ save/restore tests Kumar Kartikeya Dwivedi
2024-11-21 20:43 ` Eduard Zingerman
2024-11-21 22:07 ` Kumar Kartikeya Dwivedi
2024-11-21 23:09 ` 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=4be3db522e31ea88119751d4e2d64a9e90397f6c.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=kkd@meta.com \
--cc=martin.lau@kernel.org \
--cc=memxor@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.