Re: [PATCH for-next v5 2/2] RDMA/efa: Add AH cache handling on create and destroy AH

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Jul 06, 2026 at 03:20:07PM +0300, Leon Romanovsky wrote:
> On Sun, Jul 05, 2026 at 02:08:52PM +0000, Yonatan Nachum wrote:
> > On Sun, Jul 05, 2026 at 04:35:06PM +0300, Leon Romanovsky wrote:
> > > > +/**
> > > > + * efa_ah_cache_put - Put a refcount of an AH cache entry
> > > > + * @ah_cache: AH cache
> > > > + * @entry: AH cache entry
> > > > + *
> > > > + * Drop the refcount. If it reaches zero, remove the entry from the hashtable
> > > > + * and free it.
> > > > + */
> > > > +void efa_ah_cache_put(struct efa_ah_cache *ah_cache, struct efa_ah_cache_entry *entry)
> > > > +{
> > > > +	if (!refcount_dec_and_mutex_lock(&entry->refcount, &ah_cache->lock))
> > > > +		return;
> > > > +
> > > > +	/* AH cache lock is held here */
> > > > +	rhashtable_remove_fast(&ah_cache->hashtable, &entry->linkage, ah_cache_params);
> > > > +	mutex_unlock(&ah_cache->lock);
> > > > +
> > > > +	mutex_destroy(&entry->lock);
> > > > +	kfree_rcu(entry, rcu_head);
> > > 
> > > Where do you use RCU locking in this series? Why do you call
> > > kfree_rcu() instead of kfree()?
> > > 
> > > Thanks
> > 
> > Originally I used kfree directly, but changed to kfree_rcu in v3
> > following this Sashiko review and Jason's comment:
> > https://sashiko.dev/#/patchset/20260512061121.2177521-1-ynachum%40amazon.com
> > 
> > If you think its not needed I can delete it.
> 
> I'm not sure you're using the right data structure for this task.
> 
> An RCU grace period is required to ensure that rhash has been unlinked
> from ah_cache->hashtable, since a concurrent lookup may still succeed in
> finding the deleted entry. 

It doesn't look like this uses RCU for lookup

> The problem is that the refcount has already been decremented to 0,
> and any attempt to increment it will trigger a dmesg splat.

Sashiko claimed this was for some worker thread internal to rhashtable

Jason