All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uladzislau Rezki <urezki@gmail.com>
To: "Paul E. McKenney" <paulmck@kernel.org>,
	Vlastimil Babka <vbabka@suse.cz>
Cc: "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,
	Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH 00/14] replace call_rcu by kfree_rcu for simple kmem_cache_free callback
Date: Thu, 13 Jun 2024 15:06:54 +0200	[thread overview]
Message-ID: <Zmru7hhz8kPDPsyz@pc636> (raw)
In-Reply-To: <80e03b02-7e24-4342-af0b-ba5117b19828@paulmck-laptop>

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?

--
Uladzislau Rezki

WARNING: multiple messages have this Message-ID (diff)
From: Uladzislau Rezki <urezki@gmail.com>
To: "Paul E. McKenney" <paulmck@kernel.org>,
	Vlastimil Babka <vbabka@suse.cz>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	kvm@vger.kernel.org, Neil Brown <neilb@suse.de>,
	kernel-janitors@vger.kernel.org,
	Olga Kornievskaia <kolga@netapp.com>,
	Dai Ngo <Dai.Ngo@oracle.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	coreteam@netfilter.org,
	"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
	Jakub Kicinski <kuba@kernel.org>,
	linux-trace-kernel@vger.kernel.org, bridge@lists.linux.dev,
	ecryptfs@vger.kernel.org, Nicholas Piggin <npiggin@gmail.com>,
	linux-can@vger.kernel.org, linux-block@vger.kernel.org,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Vlastimil Babka <vbabka@suse.cz>, Tom Talpey <tom@talpey.com>,
	linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	linux-kernel@vger.kernel.org,
	Julia Lawall <Julia.Lawall@inria.fr>,
	netfilter-devel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	wireguard@lists.zx2c4.com
Subject: Re: [PATCH 00/14] replace call_rcu by kfree_rcu for simple kmem_cache_free callback
Date: Thu, 13 Jun 2024 15:06:54 +0200	[thread overview]
Message-ID: <Zmru7hhz8kPDPsyz@pc636> (raw)
In-Reply-To: <80e03b02-7e24-4342-af0b-ba5117b19828@paulmck-laptop>

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?

--
Uladzislau Rezki

  reply	other threads:[~2024-06-13 13:07 UTC|newest]

Thread overview: 158+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-09  8:27 [PATCH 00/14] replace call_rcu by kfree_rcu for simple kmem_cache_free callback Julia Lawall
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-09  8:27 ` [PATCH 02/14] net: " Julia Lawall
2024-06-09  8:27 ` [PATCH 03/14] KVM: PPC: " Julia Lawall
2024-06-09  8:27   ` Julia Lawall
2024-06-09  8:27 ` [PATCH 04/14] xfrm6_tunnel: " Julia Lawall
2024-06-09  8:27 ` [PATCH 05/14] tracefs: " Julia Lawall
2024-06-10 15:22   ` Steven Rostedt
2024-06-10 15:46     ` Paul E. McKenney
2024-06-10 20:36       ` Steven Rostedt
2024-06-10 21:40         ` Vlastimil Babka
2024-06-11  6:23           ` Greg KH
2024-06-11  8:42             ` Vlastimil Babka
2024-06-11  9:05               ` Thorsten Leemhuis
2024-06-11 14:14               ` Steven Rostedt
2024-06-12 14:09                 ` Jason A. Donenfeld
2024-06-12 16:04                   ` Steven Rostedt
2024-06-11 14:12             ` Steven Rostedt
2024-06-10 20:42       ` Vlastimil Babka
2024-06-10 21:18         ` Steven Rostedt
2024-06-09  8:27 ` [PATCH 06/14] eCryptfs: " Julia Lawall
2024-06-09  8:27 ` [PATCH 07/14] net: bridge: " Julia Lawall
2024-06-09  9:04   ` Nikolay Aleksandrov
2024-06-09  8:27 ` [PATCH 08/14] nfsd: " Julia Lawall
2024-06-09 10:53   ` Jeff Layton
2024-06-09 15:43   ` Chuck Lever
2024-06-09  8:27 ` [PATCH 09/14] block: " Julia Lawall
2024-06-09  8:27 ` [PATCH 10/14] can: gw: " Julia Lawall
2024-06-10 12:46   ` Oliver Hartkopp
2024-06-09  8:27 ` [PATCH 11/14] posix-timers: " Julia Lawall
2024-06-09  8:27 ` [PATCH 12/14] workqueue: " Julia Lawall
2024-06-10 20:31   ` Tejun Heo
2024-06-09  8:27 ` [PATCH 13/14] kcm: " Julia Lawall
2024-06-09  8:27 ` [PATCH 14/14] netfilter: " Julia Lawall
2024-06-12 21:33 ` [PATCH 00/14] " Jakub Kicinski
2024-06-12 21:33   ` Jakub Kicinski
2024-06-12 22:37   ` Paul E. McKenney
2024-06-12 22:37     ` Paul E. McKenney
2024-06-12 22:46     ` Jakub Kicinski
2024-06-12 22:46       ` Jakub Kicinski
2024-06-12 22:52     ` Jens Axboe
2024-06-12 22:52       ` Jens Axboe
2024-06-12 23:04       ` Paul E. McKenney
2024-06-12 23:04         ` Paul E. McKenney
2024-06-12 23:31     ` Jason A. Donenfeld
2024-06-12 23:31       ` Jason A. Donenfeld
2024-06-13  0:31       ` Jason A. Donenfeld
2024-06-13  0:31         ` Jason A. Donenfeld
2024-06-13  3:38         ` Paul E. McKenney
2024-06-13  3:38           ` Paul E. McKenney
2024-06-13 12:22           ` Jason A. Donenfeld
2024-06-13 12:22             ` Jason A. Donenfeld
2024-06-13 12:46             ` Paul E. McKenney
2024-06-13 12:46               ` Paul E. McKenney
2024-06-13 14:11               ` Jason A. Donenfeld
2024-06-13 14:11                 ` Jason A. Donenfeld
2024-06-13 15:12                 ` Paul E. McKenney
2024-06-13 15:12                   ` Paul E. McKenney
2024-06-17 15:10             ` Vlastimil Babka
2024-06-17 15:10               ` Vlastimil Babka
2024-06-17 16:12               ` Paul E. McKenney
2024-06-17 16:12                 ` Paul E. McKenney
2024-06-17 17:23                 ` Vlastimil Babka
2024-06-17 17:23                   ` Vlastimil Babka
2024-06-17 18:42                   ` Uladzislau Rezki
2024-06-17 18:42                     ` Uladzislau Rezki
2024-06-17 21:08                     ` Vlastimil Babka
2024-06-17 21:08                       ` Vlastimil Babka
2024-06-18  9:31                       ` Uladzislau Rezki
2024-06-18  9:31                         ` Uladzislau Rezki
2024-06-18 16:48                         ` Paul E. McKenney
2024-06-18 16:48                           ` Paul E. McKenney
2024-06-18 17:21                           ` Vlastimil Babka
2024-06-18 17:21                             ` Vlastimil Babka
2024-06-18 17:53                             ` Paul E. McKenney
2024-06-18 17:53                               ` Paul E. McKenney
2024-06-19  9:28                               ` Vlastimil Babka
2024-06-19  9:28                                 ` Vlastimil Babka
2024-06-19 16:46                                 ` Paul E. McKenney
2024-06-19 16:46                                   ` Paul E. McKenney
2024-06-21  9:32                                 ` Uladzislau Rezki
2024-06-21  9:32                                   ` Uladzislau Rezki
2024-07-15 20:39                                   ` Vlastimil Babka
2024-07-15 20:39                                     ` Vlastimil Babka
2024-07-24 13:53                                     ` Paul E. McKenney
2024-07-24 13:53                                       ` Paul E. McKenney
2024-07-24 14:40                                       ` Vlastimil Babka
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:51                             ` Uladzislau Rezki
2024-06-19  9:56                             ` Vlastimil Babka
2024-06-19  9:56                               ` Vlastimil Babka
2024-06-19 11:22                               ` Uladzislau Rezki
2024-06-19 11:22                                 ` Uladzislau Rezki
2024-06-17 18:54                   ` Paul E. McKenney
2024-06-17 18:54                     ` Paul E. McKenney
2024-06-17 21:34                     ` Vlastimil Babka
2024-06-17 21:34                       ` Vlastimil Babka
2024-06-13 14:17           ` Jakub Kicinski
2024-06-13 14:17             ` Jakub Kicinski
2024-06-13 14:53             ` Paul E. McKenney
2024-06-13 14:53               ` Paul E. McKenney
2024-06-13 11:58     ` Jason A. Donenfeld
2024-06-13 11:58       ` Jason A. Donenfeld
2024-06-13 12:47       ` Paul E. McKenney
2024-06-13 12:47         ` Paul E. McKenney
2024-06-13 13:06         ` Uladzislau Rezki [this message]
2024-06-13 13:06           ` Uladzislau Rezki
2024-06-13 15:06           ` Paul E. McKenney
2024-06-13 15:06             ` Paul E. McKenney
2024-06-13 17:38             ` Uladzislau Rezki
2024-06-13 17:38               ` Uladzislau Rezki
2024-06-13 17:45               ` Paul E. McKenney
2024-06-13 17:45                 ` Paul E. McKenney
2024-06-13 17:58                 ` Uladzislau Rezki
2024-06-13 17:58                   ` Uladzislau Rezki
2024-06-13 18:13                   ` Paul E. McKenney
2024-06-13 18:13                     ` Paul E. McKenney
2024-06-14 12:35                     ` Uladzislau Rezki
2024-06-14 12:35                       ` Uladzislau Rezki
2024-06-14 14:17                       ` Paul E. McKenney
2024-06-14 14:17                         ` Paul E. McKenney
2024-06-14 14:50                         ` Uladzislau Rezki
2024-06-14 14:50                           ` Uladzislau Rezki
2024-06-14 19:33                       ` Jason A. Donenfeld
2024-06-14 19:33                         ` Jason A. Donenfeld
2024-06-17 13:50                         ` Uladzislau Rezki
2024-06-17 13:50                           ` Uladzislau Rezki
2024-06-17 14:56                           ` Jason A. Donenfeld
2024-06-17 14:56                             ` Jason A. Donenfeld
2024-06-17 16:30                             ` Uladzislau Rezki
2024-06-17 16:30                               ` Uladzislau Rezki
2024-06-17 16:33                               ` Jason A. Donenfeld
2024-06-17 16:33                                 ` Jason A. Donenfeld
2024-06-17 16:38                                 ` Vlastimil Babka
2024-06-17 16:38                                   ` Vlastimil Babka
2024-06-17 17:04                                   ` Jason A. Donenfeld
2024-06-17 17:04                                     ` Jason A. Donenfeld
2024-06-17 21:19                                     ` Vlastimil Babka
2024-06-17 21:19                                       ` Vlastimil Babka
2024-06-17 16:42                                 ` Uladzislau Rezki
2024-06-17 16:42                                   ` Uladzislau Rezki
2024-06-17 16:57                                   ` Jason A. Donenfeld
2024-06-17 16:57                                     ` Jason A. Donenfeld
2024-06-17 17:19                                     ` Uladzislau Rezki
2024-06-17 17:19                                       ` Uladzislau Rezki
2024-06-17 14:37                         ` Vlastimil Babka
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=Zmru7hhz8kPDPsyz@pc636 \
    --to=urezki@gmail.com \
    --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=paulmck@kernel.org \
    --cc=tom@talpey.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 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.