From: David Vernet <void@manifault.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Hou Tao <houtao@huaweicloud.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Tejun Heo <tj@kernel.org>,
rcu@vger.kernel.org, Network Development <netdev@vger.kernel.org>,
bpf <bpf@vger.kernel.org>, Kernel Team <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 13:01:47 -0500 [thread overview]
Message-ID: <20230626180147.GB6750@maniforge> (raw)
In-Reply-To: <CAADnVQ+vBRZ3ySX-YOVQnfL-J4UV1pJymXxee-AqjGGAHtv2Jg@mail.gmail.com>
On Mon, Jun 26, 2023 at 10:59:40AM -0700, Alexei Starovoitov wrote:
> On Mon, Jun 26, 2023 at 10:55 AM David Vernet <void@manifault.com> wrote:
> >
> > > > > +
> > > > > + 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()?
> > >
> > > migrate_disable/enable() are actually not necessary here.
> > > We can call bpf_mem_cache_free_rcu() directly from any kfunc.
> >
> > Could you please clarify why? Can't we migrate if the kfunc is called
> > from a sleepable struct_ops callback?
>
> migration is disabled for all bpf progs including sleepable.
Fair enough :-) Then yep, let's remove these. Feel free to do so when
you send v2, and keep my Ack. Otherwise I'm happy to send a follow-on
patch after this series is merged.
next prev parent reply other threads:[~2023-06-26 18:01 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
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 [this message]
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=20230626180147.GB6750@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.