linux-kernel - Re: [PATCH 05/14] tracefs: replace call_rcu by kfree_rcu for simple kmem_cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240610163606.069d552a@gandalf.local.home>
Date: Mon, 10 Jun 2024 16:36:06 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: Julia Lawall <Julia.Lawall@...ia.fr>, kernel-janitors@...r.kernel.org,
 Masami Hiramatsu <mhiramat@...nel.org>, Mathieu Desnoyers
 <mathieu.desnoyers@...icios.com>, linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH 05/14] tracefs: replace call_rcu by kfree_rcu for simple
 kmem_cache_free callback

On Mon, 10 Jun 2024 08:46:42 -0700
"Paul E. McKenney" <paulmck@...nel.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@...dmis.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