From: "Paul E. McKenney" <paulmck@kernel.org>
To: Uladzislau Rezki <urezki@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Jakub Kicinski <kuba@kernel.org>,
Julia Lawall <Julia.Lawall@inria.fr>,
linux-block@vger.kernel.org, kernel-janitors@vger.kernel.org,
bridge@lists.linux.dev, linux-trace-kernel@vger.kernel.org,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
kvm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Nicholas Piggin <npiggin@gmail.com>,
netdev@vger.kernel.org, wireguard@lists.zx2c4.com,
linux-kernel@vger.kernel.org, ecryptfs@vger.kernel.org,
Neil Brown <neilb@suse.de>, Olga Kornievskaia <kolga@netapp.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
linux-nfs@vger.kernel.org, linux-can@vger.kernel.org,
Lai Jiangshan <jiangshanlai@gmail.com>,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org
Subject: Re: [PATCH 00/14] replace call_rcu by kfree_rcu for simple kmem_cache_free callback
Date: Thu, 13 Jun 2024 10:45:59 -0700 [thread overview]
Message-ID: <cb51bc57-47b8-456a-9ac0-f8aa0931b144@paulmck-laptop> (raw)
In-Reply-To: <Zmsuswo8OPIhY5KJ@pc636>
On Thu, Jun 13, 2024 at 07:38:59PM +0200, Uladzislau Rezki wrote:
> On Thu, Jun 13, 2024 at 08:06:30AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 13, 2024 at 03:06:54PM +0200, Uladzislau Rezki wrote:
> > > On Thu, Jun 13, 2024 at 05:47:08AM -0700, Paul E. McKenney wrote:
> > > > On Thu, Jun 13, 2024 at 01:58:59PM +0200, Jason A. Donenfeld wrote:
> > > > > On Wed, Jun 12, 2024 at 03:37:55PM -0700, Paul E. McKenney wrote:
> > > > > > On Wed, Jun 12, 2024 at 02:33:05PM -0700, Jakub Kicinski wrote:
> > > > > > > On Sun, 9 Jun 2024 10:27:12 +0200 Julia Lawall wrote:
> > > > > > > > Since SLOB was removed, it is not necessary to use call_rcu
> > > > > > > > when the callback only performs kmem_cache_free. Use
> > > > > > > > kfree_rcu() directly.
> > > > > > > >
> > > > > > > > The changes were done using the following Coccinelle semantic patch.
> > > > > > > > This semantic patch is designed to ignore cases where the callback
> > > > > > > > function is used in another way.
> > > > > > >
> > > > > > > How does the discussion on:
> > > > > > > [PATCH] Revert "batman-adv: prefer kfree_rcu() over call_rcu() with free-only callbacks"
> > > > > > > https://lore.kernel.org/all/20240612133357.2596-1-linus.luessing@c0d3.blue/
> > > > > > > reflect on this series? IIUC we should hold off..
> > > > > >
> > > > > > We do need to hold off for the ones in kernel modules (such as 07/14)
> > > > > > where the kmem_cache is destroyed during module unload.
> > > > > >
> > > > > > OK, I might as well go through them...
> > > > > >
> > > > > > [PATCH 01/14] wireguard: allowedips: replace call_rcu by kfree_rcu for simple kmem_cache_free callback
> > > > > > Needs to wait, see wg_allowedips_slab_uninit().
> > > > >
> > > > > Also, notably, this patch needs additionally:
> > > > >
> > > > > diff --git a/drivers/net/wireguard/allowedips.c b/drivers/net/wireguard/allowedips.c
> > > > > index e4e1638fce1b..c95f6937c3f1 100644
> > > > > --- a/drivers/net/wireguard/allowedips.c
> > > > > +++ b/drivers/net/wireguard/allowedips.c
> > > > > @@ -377,7 +377,6 @@ int __init wg_allowedips_slab_init(void)
> > > > >
> > > > > void wg_allowedips_slab_uninit(void)
> > > > > {
> > > > > - rcu_barrier();
> > > > > kmem_cache_destroy(node_cache);
> > > > > }
> > > > >
> > > > > Once kmem_cache_destroy has been fixed to be deferrable.
> > > > >
> > > > > I assume the other patches are similar -- an rcu_barrier() can be
> > > > > removed. So some manual meddling of these might be in order.
> > > >
> > > > Assuming that the deferrable kmem_cache_destroy() is the option chosen,
> > > > agreed.
> > > >
> > > <snip>
> > > void kmem_cache_destroy(struct kmem_cache *s)
> > > {
> > > int err = -EBUSY;
> > > bool rcu_set;
> > >
> > > if (unlikely(!s) || !kasan_check_byte(s))
> > > return;
> > >
> > > cpus_read_lock();
> > > mutex_lock(&slab_mutex);
> > >
> > > rcu_set = s->flags & SLAB_TYPESAFE_BY_RCU;
> > >
> > > s->refcount--;
> > > if (s->refcount)
> > > goto out_unlock;
> > >
> > > err = shutdown_cache(s);
> > > WARN(err, "%s %s: Slab cache still has objects when called from %pS",
> > > __func__, s->name, (void *)_RET_IP_);
> > > ...
> > > cpus_read_unlock();
> > > if (!err && !rcu_set)
> > > kmem_cache_release(s);
> > > }
> > > <snip>
> > >
> > > so we have SLAB_TYPESAFE_BY_RCU flag that defers freeing slab-pages
> > > and a cache by a grace period. Similar flag can be added, like
> > > SLAB_DESTROY_ONCE_FULLY_FREED, in this case a worker rearm itself
> > > if there are still objects which should be freed.
> > >
> > > Any thoughts here?
> >
> > Wouldn't we also need some additional code to later check for all objects
> > being freed to the slab, whether or not that code is initiated from
> > kmem_cache_destroy()?
> >
> Same away as SLAB_TYPESAFE_BY_RCU is handled from the kmem_cache_destroy() function.
> It checks that flag and if it is true and extra worker is scheduled to perform a
> deferred(instead of right away) destroy after rcu_barrier() finishes.
Like this?
SLAB_DESTROY_ONCE_FULLY_FREED
Instead of adding a new kmem_cache_destroy_rcu()
or kmem_cache_destroy_wait() API member, instead add a
SLAB_DESTROY_ONCE_FULLY_FREED flag that can be passed to the
existing kmem_cache_destroy() function. Use of this flag would
suppress any warnings that would otherwise be issued if there
was still slab memory yet to be freed, and it would also spawn
workqueues (or timers or whatever) to do any needed cleanup work.
Thanx, Paul
next prev parent reply other threads:[~2024-06-13 17:49 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-09 8:27 Julia Lawall
2024-06-09 8:27 ` [PATCH 01/14] wireguard: allowedips: " Julia Lawall
2024-06-09 14:32 ` Jason A. Donenfeld
2024-06-09 14:36 ` Julia Lawall
2024-06-10 20:38 ` Vlastimil Babka
2024-06-10 20:59 ` Jason A. Donenfeld
2024-06-12 21:33 ` [PATCH 00/14] " Jakub Kicinski
2024-06-12 22:37 ` Paul E. McKenney
2024-06-12 22:46 ` Jakub Kicinski
2024-06-12 22:52 ` Jens Axboe
2024-06-12 23:04 ` Paul E. McKenney
2024-06-12 23:31 ` Jason A. Donenfeld
2024-06-13 0:31 ` Jason A. Donenfeld
2024-06-13 3:38 ` Paul E. McKenney
2024-06-13 12:22 ` Jason A. Donenfeld
2024-06-13 12:46 ` Paul E. McKenney
2024-06-13 14:11 ` Jason A. Donenfeld
2024-06-13 15:12 ` Paul E. McKenney
2024-06-17 15:10 ` Vlastimil Babka
2024-06-17 16:12 ` Paul E. McKenney
2024-06-17 17:23 ` Vlastimil Babka
2024-06-17 18:42 ` Uladzislau Rezki
2024-06-17 21:08 ` Vlastimil Babka
2024-06-18 9:31 ` Uladzislau Rezki
2024-06-18 16:48 ` Paul E. McKenney
2024-06-18 17:21 ` Vlastimil Babka
2024-06-18 17:53 ` Paul E. McKenney
2024-06-19 9:28 ` Vlastimil Babka
2024-06-19 16:46 ` Paul E. McKenney
2024-06-21 9:32 ` Uladzislau Rezki
2024-07-15 20:39 ` Vlastimil Babka
2024-07-24 13:53 ` Paul E. McKenney
2024-07-24 14:40 ` Vlastimil Babka
2024-10-08 16:41 ` Vlastimil Babka
2024-10-08 20:02 ` Paul E. McKenney
2024-10-09 17:08 ` Julia Lawall
2024-10-09 21:02 ` Paul E. McKenney
2024-06-19 9:51 ` Uladzislau Rezki
2024-06-19 9:56 ` Vlastimil Babka
2024-06-19 11:22 ` Uladzislau Rezki
2024-06-17 18:54 ` Paul E. McKenney
2024-06-17 21:34 ` Vlastimil Babka
2024-06-13 14:17 ` Jakub Kicinski
2024-06-13 14:53 ` Paul E. McKenney
2024-06-13 11:58 ` Jason A. Donenfeld
2024-06-13 12:47 ` Paul E. McKenney
2024-06-13 13:06 ` Uladzislau Rezki
2024-06-13 15:06 ` Paul E. McKenney
2024-06-13 17:38 ` Uladzislau Rezki
2024-06-13 17:45 ` Paul E. McKenney [this message]
2024-06-13 17:58 ` Uladzislau Rezki
2024-06-13 18:13 ` Paul E. McKenney
2024-06-14 12:35 ` Uladzislau Rezki
2024-06-14 14:17 ` Paul E. McKenney
2024-06-14 14:50 ` Uladzislau Rezki
2024-06-14 19:33 ` Jason A. Donenfeld
2024-06-17 13:50 ` Uladzislau Rezki
2024-06-17 14:56 ` Jason A. Donenfeld
2024-06-17 16:30 ` Uladzislau Rezki
2024-06-17 16:33 ` Jason A. Donenfeld
2024-06-17 16:38 ` Vlastimil Babka
2024-06-17 17:04 ` Jason A. Donenfeld
2024-06-17 21:19 ` Vlastimil Babka
2024-06-17 16:42 ` Uladzislau Rezki
2024-06-17 16:57 ` Jason A. Donenfeld
2024-06-17 17:19 ` Uladzislau Rezki
2024-06-17 14:37 ` Vlastimil Babka
2024-10-08 16:36 ` Vlastimil Babka
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=cb51bc57-47b8-456a-9ac0-f8aa0931b144@paulmck-laptop \
--to=paulmck@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=Jason@zx2c4.com \
--cc=Julia.Lawall@inria.fr \
--cc=bridge@lists.linux.dev \
--cc=christophe.leroy@csgroup.eu \
--cc=coreteam@netfilter.org \
--cc=ecryptfs@vger.kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=kolga@netapp.com \
--cc=kuba@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=naveen.n.rao@linux.ibm.com \
--cc=neilb@suse.de \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=npiggin@gmail.com \
--cc=tom@talpey.com \
--cc=urezki@gmail.com \
--cc=vbabka@suse.cz \
--cc=wireguard@lists.zx2c4.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).