From: Steven Rostedt <rostedt@goodmis.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Julia Lawall <Julia.Lawall@inria.fr>,
kernel-janitors@vger.kernel.org,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH 05/14] tracefs: replace call_rcu by kfree_rcu for simple kmem_cache_free callback
Date: Mon, 10 Jun 2024 16:36:06 -0400 [thread overview]
Message-ID: <20240610163606.069d552a@gandalf.local.home> (raw)
In-Reply-To: <b647eacd-f6f3-4960-acfd-36c30f376995@paulmck-laptop>
On Mon, 10 Jun 2024 08:46:42 -0700
"Paul E. McKenney" <paulmck@kernel.org> wrote:
> > > index 7c29f4afc23d..338c52168e61 100644
> > > --- a/fs/tracefs/inode.c
> > > +++ b/fs/tracefs/inode.c
> > > @@ -53,14 +53,6 @@ static struct inode *tracefs_alloc_inode(struct super_block *sb)
> > > return &ti->vfs_inode;
> > > }
> > >
> > > -static void tracefs_free_inode_rcu(struct rcu_head *rcu)
> > > -{
> > > - struct tracefs_inode *ti;
> > > -
> > > - ti = container_of(rcu, struct tracefs_inode, rcu);
> > > - kmem_cache_free(tracefs_inode_cachep, ti);
> >
> > Does this work?
> >
> > tracefs needs to be freed via the tracefs_inode_cachep. Does
> > kfree_rcu() handle specific frees for objects that were not allocated
> > via kmalloc()?
>
> A recent change to kfree() allows it to correctly handle memory allocated
> via kmem_cache_alloc(). News to me as of a few weeks ago. ;-)
If that's the case then:
Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Do we have a way to add a "Depends-on" tag so that anyone backporting this
will know that it requires the change to whatever allowed that to happen?
Or we need to update the change log to explicitly state that this should
*not* be backported.
-- Steve
next prev parent reply other threads:[~2024-06-10 20:35 UTC|newest]
Thread overview: 77+ 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 ` [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 [this message]
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-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=20240610163606.069d552a@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=Julia.Lawall@inria.fr \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=paulmck@kernel.org \
--cc=vbabka@suse.cz \
/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).