Re: [cocci] patch idea: convert trivial call_rcu users to kfree_rcu

[Uladzislau Rezki <urezki@gmail.com>]

On Tue, Jun 11, 2024 at 10:25:52AM -0700, Paul E. McKenney wrote:
> On Tue, Jun 11, 2024 at 06:40:49PM +0200, Uladzislau Rezki wrote:
> > > > 
> > > > These look ok to me.  In the last two cases, the callback function is also
> > > > stored in a data structure, eg:
> > > > 
> > > > static struct mfc6_cache *ip6mr_cache_alloc(void)
> > > > {
> > > > 	struct mfc6_cache *c = kmem_cache_zalloc(mrt_cachep, GFP_KERNEL);
> > > > 	if (!c)
> > > > 		return NULL;
> > > > 	c->_c.mfc_un.res.last_assert = jiffies - MFC_ASSERT_THRESH - 1;
> > > > 	c->_c.mfc_un.res.minvif = MAXMIFS;
> > > > 	c->_c.free = ip6mr_cache_free_rcu;
> > > > 	refcount_set(&c->_c.mfc_un.res.refcount, 1);
> > > > 	return c;
> > > > }
> > > > 
> > > > Should that be left as it is?
> > > 
> > > Given that ->_c.free isn't used in the RCU callback, I am guessing that
> > > this is intended for debugging purposes, so that you can see from a crash
> > > dump how this will be freed.  But I could be completely off-base here.
> > > 
> > > One approach would be to remove the ->_c.free field and call attention
> > > to this in the patches' commit logs.
> > > 
> > > Another would be to instead put the address of the allocation function
> > > in ->_c.free, and again call attention to this in the commit logs.
> > > 
> > > Is there a better approach than these three?  ;-)
> > > 
> > IMO, "_c.free" should be removed:
> 
> Why not send the patch and see what the maintainers say?  If they object,
> you can always fall back to one of the other two methods, depending on
> the nature of their objection.
> 
I can send the patch :)

--
Uladzislau Rezki