From: David Vernet <void@manifault.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: daniel@iogearbox.net, andrii@kernel.org, houtao@huaweicloud.com,
paulmck@kernel.org, tj@kernel.org, rcu@vger.kernel.org,
netdev@vger.kernel.org, bpf@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH v2 bpf-next 13/13] bpf: Convert bpf_cpumask to bpf_mem_cache_free_rcu.
Date: Mon, 26 Jun 2023 10:42:28 -0500 [thread overview]
Message-ID: <20230626154228.GA6798@maniforge> (raw)
In-Reply-To: <20230624031333.96597-14-alexei.starovoitov@gmail.com>
On Fri, Jun 23, 2023 at 08:13:33PM -0700, Alexei Starovoitov wrote:
> From: Alexei Starovoitov <ast@kernel.org>
>
> Convert bpf_cpumask to bpf_mem_cache_free_rcu.
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: David Vernet <void@manifault.com>
LGTM, thanks for cleaning this up. I left one drive-by comment /
observation below, but it's not a blocker for this patch / series.
> ---
> kernel/bpf/cpumask.c | 20 ++++++--------------
> 1 file changed, 6 insertions(+), 14 deletions(-)
>
> diff --git a/kernel/bpf/cpumask.c b/kernel/bpf/cpumask.c
> index 938a60ff4295..6983af8e093c 100644
> --- a/kernel/bpf/cpumask.c
> +++ b/kernel/bpf/cpumask.c
> @@ -9,7 +9,6 @@
> /**
> * struct bpf_cpumask - refcounted BPF cpumask wrapper structure
> * @cpumask: The actual cpumask embedded in the struct.
> - * @rcu: The RCU head used to free the cpumask with RCU safety.
> * @usage: Object reference counter. When the refcount goes to 0, the
> * memory is released back to the BPF allocator, which provides
> * RCU safety.
> @@ -25,7 +24,6 @@
> */
> struct bpf_cpumask {
> cpumask_t cpumask;
> - struct rcu_head rcu;
> refcount_t usage;
> };
>
> @@ -82,16 +80,6 @@ __bpf_kfunc struct bpf_cpumask *bpf_cpumask_acquire(struct bpf_cpumask *cpumask)
> return cpumask;
> }
>
> -static void cpumask_free_cb(struct rcu_head *head)
> -{
> - struct bpf_cpumask *cpumask;
> -
> - cpumask = container_of(head, struct bpf_cpumask, rcu);
> - migrate_disable();
> - bpf_mem_cache_free(&bpf_cpumask_ma, cpumask);
> - migrate_enable();
> -}
> -
> /**
> * bpf_cpumask_release() - Release a previously acquired BPF cpumask.
> * @cpumask: The cpumask being released.
> @@ -102,8 +90,12 @@ static void cpumask_free_cb(struct rcu_head *head)
> */
> __bpf_kfunc void bpf_cpumask_release(struct bpf_cpumask *cpumask)
> {
> - if (refcount_dec_and_test(&cpumask->usage))
> - call_rcu(&cpumask->rcu, cpumask_free_cb);
> + if (!refcount_dec_and_test(&cpumask->usage))
> + return;
> +
> + migrate_disable();
> + bpf_mem_cache_free_rcu(&bpf_cpumask_ma, cpumask);
> + migrate_enable();
The fact that callers have to disable migration like this in order to
safely free the memory feels a bit leaky. Is there any reason we can't
move this into bpf_mem_{cache_}free_rcu()?
next prev parent reply other threads:[~2023-06-26 15:42 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-24 3:13 [PATCH v2 bpf-next 00/13] bpf: Introduce bpf_mem_cache_free_rcu() Alexei Starovoitov
2023-06-24 3:13 ` [PATCH v2 bpf-next 01/13] bpf: Rename few bpf_mem_alloc fields Alexei Starovoitov
2023-06-24 3:13 ` [PATCH v2 bpf-next 02/13] bpf: Simplify code of destroy_mem_alloc() with kmemdup() Alexei Starovoitov
2023-06-24 3:13 ` [PATCH v2 bpf-next 03/13] bpf: Let free_all() return the number of freed elements Alexei Starovoitov
2023-06-24 3:13 ` [PATCH v2 bpf-next 04/13] bpf: Refactor alloc_bulk() Alexei Starovoitov
2023-06-24 3:13 ` [PATCH v2 bpf-next 05/13] bpf: Further refactor alloc_bulk() Alexei Starovoitov
2023-06-24 3:13 ` [PATCH v2 bpf-next 06/13] bpf: Optimize moving objects from free_by_rcu_ttrace to waiting_for_gp_ttrace Alexei Starovoitov
2023-06-24 3:13 ` [PATCH v2 bpf-next 07/13] bpf: Change bpf_mem_cache draining process Alexei Starovoitov
2023-06-24 3:13 ` [PATCH v2 bpf-next 08/13] bpf: Add a hint to allocated objects Alexei Starovoitov
2023-06-24 3:13 ` [PATCH v2 bpf-next 09/13] bpf: Allow reuse from waiting_for_gp_ttrace list Alexei Starovoitov
2023-06-26 3:30 ` Hou Tao
2023-06-26 4:42 ` Alexei Starovoitov
2023-06-26 7:16 ` Hou Tao
2023-06-28 0:59 ` Alexei Starovoitov
2023-06-28 8:09 ` Hou Tao
2023-06-28 17:38 ` Paul E. McKenney
2023-06-24 3:13 ` [PATCH v2 bpf-next 10/13] rcu: Export rcu_request_urgent_qs_task() Alexei Starovoitov
2023-06-24 3:13 ` [PATCH v2 bpf-next 11/13] selftests/bpf: Improve test coverage of bpf_mem_alloc Alexei Starovoitov
2023-06-24 3:13 ` [PATCH v2 bpf-next 12/13] bpf: Introduce bpf_mem_free_rcu() similar to kfree_rcu() Alexei Starovoitov
2023-06-24 6:49 ` Hou Tao
2023-06-25 11:20 ` Hou Tao
2023-06-28 0:52 ` Alexei Starovoitov
2023-06-28 1:36 ` Hou Tao
2023-06-24 7:53 ` Hou Tao
2023-06-28 0:54 ` Alexei Starovoitov
2023-06-24 9:05 ` Hou Tao
2023-06-25 11:15 ` Hou Tao
2023-06-28 0:56 ` Alexei Starovoitov
2023-06-28 1:43 ` Hou Tao
2023-06-28 1:51 ` Alexei Starovoitov
2023-06-28 2:03 ` Hou Tao
2023-06-24 3:13 ` [PATCH v2 bpf-next 13/13] bpf: Convert bpf_cpumask to bpf_mem_cache_free_rcu Alexei Starovoitov
2023-06-26 15:42 ` David Vernet [this message]
2023-06-26 16:09 ` Alexei Starovoitov
2023-06-26 17:55 ` David Vernet
2023-06-26 17:59 ` Alexei Starovoitov
2023-06-26 18:01 ` David Vernet
2023-06-24 7:09 ` [PATCH v2 bpf-next 00/13] bpf: Introduce bpf_mem_cache_free_rcu() Hou Tao
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=20230626154228.GA6798@maniforge \
--to=void@manifault.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=houtao@huaweicloud.com \
--cc=kernel-team@fb.com \
--cc=netdev@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=tj@kernel.org \
/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.