All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Chenguang Zhao <zhaochenguang@kylinos.cn>
Cc: Jason Gunthorpe <jgg@ziepe.ca>, Kees Cook <kees@kernel.org>,
	Etienne AUJAMES <eaujames@ddn.com>,
	zhenwei pi <zhenwei.pi@linux.dev>, Jiri Pirko <jiri@resnulli.us>,
	Maor Gottlieb <maorg@nvidia.com>,
	linux-rdma@vger.kernel.org
Subject: Re: [PATCH] IB/cache: Check GID table references before attempting deletion
Date: Sun, 17 May 2026 13:32:40 +0300	[thread overview]
Message-ID: <20260517103240.GC33515@unreal> (raw)
In-Reply-To: <20260513080707.3929955-1-zhaochenguang@kylinos.cn>

On Wed, May 13, 2026 at 04:07:07PM +0800, Chenguang Zhao wrote:
> In the NFS over RDMA environment, repeatedly performing frequent
> ifdown/ifup operations on the client may cause df -h to hang.
> The kernel log reports an error:
>   __ib_cache_gid_add: unable to add gid
>   0000:0000:0000:0000:0000:ffff:c0a8:0115 error=-28.
> Error code -28 indicates the GID table is full.
> The call stack during ifdown is as follows:
>   put_gid_entry_locked()
>   del_gid()
>   _ib_cache_gid_del()
>   update_gid()
>   update_gid_event_work_handler()
> 
> In put_gid_entry_locked(), kref_put(&entry->kref) does not
> drop the reference count to zero.

Why?

> so free_gid_entry() is never invoked to release the entry. Subsequent ifup
> attempts keep adding new entries into the GID table,
> eventually exhausting the table capacity.

This behavior is not what we expect from the IB/cache layer.

Thanks

> 
> To fix this, check whether the GID entry still has
> outstanding references in del_gid(), and only remove
> and release the entry when no other references remain.
> 
> Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
> ---
>  drivers/infiniband/core/cache.c | 31 +++++++++++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/infiniband/core/cache.c b/drivers/infiniband/core/cache.c
> index 647a547e2d7f..c71522fbf89f 100644
> --- a/drivers/infiniband/core/cache.c
> +++ b/drivers/infiniband/core/cache.c
> @@ -596,6 +596,34 @@ int ib_cache_gid_add(struct ib_device *ib_dev, u32 port,
>  	return __ib_cache_gid_add(ib_dev, port, gid, attr, mask, false);
>  }
>  
> +/**
> + * gid_table_is_shared - Check if GID table has other reference owners
> + * @table: GID table to check
> + * @ix: index of entry
> + *
> + * Returns true if the gid table refcount is greater than 1,
> + */
> +static bool gid_table_is_shared(struct ib_gid_table *table, int ix)
> +{
> +	unsigned int refcount;
> +	struct ib_gid_table_entry *entry;
> +
> +	write_lock_irq(&table->rwlock);
> +
> +	entry = table->data_vec[ix];
> +	refcount = kref_read(&entry->kref);
> +
> +	write_unlock_irq(&table->rwlock);
> +
> +	if (refcount > 1) {
> +		pr_debug("%s: The GID table is still referenced and cannot be deleted.\n",
> +			__func__);
> +		return true;
> +	} else {
> +		return false;
> +	}
> +}
> +
>  static int
>  _ib_cache_gid_del(struct ib_device *ib_dev, u32 port,
>  		  union ib_gid *gid, struct ib_gid_attr *attr,
> @@ -615,6 +643,9 @@ _ib_cache_gid_del(struct ib_device *ib_dev, u32 port,
>  		goto out_unlock;
>  	}
>  
> +	if (gid_table_is_shared(table, ix))
> +		goto out_unlock;
> +
>  	del_gid(ib_dev, port, table, ix);
>  	dispatch_gid_change_event(ib_dev, port);
>  
> -- 
> 2.25.1
> 
> 

  reply	other threads:[~2026-05-17 10:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13  8:07 [PATCH] IB/cache: Check GID table references before attempting deletion Chenguang Zhao
2026-05-17 10:32 ` Leon Romanovsky [this message]
2026-05-18  2:36   ` Chenguang Zhao
2026-05-18 17:58     ` Jason Gunthorpe

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=20260517103240.GC33515@unreal \
    --to=leon@kernel.org \
    --cc=eaujames@ddn.com \
    --cc=jgg@ziepe.ca \
    --cc=jiri@resnulli.us \
    --cc=kees@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=maorg@nvidia.com \
    --cc=zhaochenguang@kylinos.cn \
    --cc=zhenwei.pi@linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.