From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Julia Lawall <Julia.Lawall@inria.fr>,
kernel-janitors@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
wireguard@lists.zx2c4.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Paul E . McKenney" <paulmck@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
linux-mm@kvack.org
Subject: Re: [PATCH 01/14] wireguard: allowedips: replace call_rcu by kfree_rcu for simple kmem_cache_free callback
Date: Mon, 10 Jun 2024 22:59:07 +0200 [thread overview]
Message-ID: <ZmdpG7sVdPqikphi@zx2c4.com> (raw)
In-Reply-To: <3f58c9a6-614f-4188-9a38-72c26fb42c8e@suse.cz>
Hi Vlastimil,
On Mon, Jun 10, 2024 at 10:38:08PM +0200, Vlastimil Babka wrote:
> On 6/9/24 4:32 PM, Jason A. Donenfeld wrote:
> > Hi Julia & Vlastimil,
> >
> > On Sun, Jun 09, 2024 at 10:27:13AM +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.
> >
> > Thanks, I applied this to the wireguard tree, and I'll send this out as
> > a fix for 6.10. Let me know if this is unfavorable to you and if you'd
> > like to take this somewhere yourself, in which case I'll give you my
> > ack.
> >
> > Just a question, though, for Vlastimil -- I know that with the SLOB
> > removal, kfree() is now allowed on kmemcache'd objects. Do you plan to
> > do a blanket s/kmem_cache_free/kfree/g at some point, and then remove
> > kmem_cache_free all together?
>
> Hmm, not really, but obligatory Cc for willy who'd love to have "one free()
> to rule them all" IIRC.
>
> My current thinking is that kmem_cache_free() can save the kmem_cache
> lookup, or serve as a double check if debugging is enabled, and doesn't have
> much downside. If someone wants to not care about the kmem_cache pointer,
> they can use kfree(). Even convert their subsystem at will. But a mass
> conversion of everything would be rather lot of churn for not much of a
> benefit, IMHO.
Huh, interesting. I can see the practical sense in that, not causing
unnecessary churn and such.
At the same time, this doesn't appeal much to some sort of orderly part
of my mind. Either all kmalloc/kmem_cache memory is kfree()d as the rule
for what is best, or a kmalloc pairs with a kfree and a kmem_cache_alloc
pairs with a kmem_cache_free and that's the rule. And those can be
checked and enforced and so forth. But saying, "oh, well, they might
work a bit different, but whatever you want is basically fine; there's
no rhyme or reason" is somehow dissatisfying. Maybe the rule is
actually, "use kmem_cache_free if you can because it saves a pointer
lookup, but don't go out of your way to do that and certainly don't
bloat .text to make it happen," then maybe that makes sense? But I
dunno, I find myself wanting a rule and consistency. (Did you find it
annoying that in this paragraph, I used () on only one function mention
but not on the others? If so, maybe you're like me.) Maybe I should just
chill though. Anyway, only my 2¢, and my opinion here isn't worth much,
so please regard this as only a gut statement from a bystander.
Jason
next prev parent reply other threads:[~2024-06-10 20:59 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-09 8:27 [PATCH 00/14] " 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 [this message]
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
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=ZmdpG7sVdPqikphi@zx2c4.com \
--to=jason@zx2c4.com \
--cc=Julia.Lawall@inria.fr \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paulmck@kernel.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--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).