On 15/09/25 1:32 pm, Leon Romanovsky wrote:

On Mon, Sep 15, 2025 at 12:24:16PM +0530, Mahanta Jambigi wrote:

quoted

On 12/09/25 2:37 pm, Leon Romanovsky wrote:

quoted

On Fri, Sep 12, 2025 at 01:18:52PM +0530, Mahanta Jambigi wrote:

quoted

On 10/09/25 3:31 pm, Leon Romanovsky wrote:

quoted

quoted

--- a/net/smc/smc_pnet.c
+++ b/net/smc/smc_pnet.c

@@ -450,7 +450,7 @@ static int smc_pnet_add_ib(struct smc_pnettable *pnettable, char *ib_name,
 		return -ENOMEM;
 	new_pe->type = SMC_PNET_IB;
 	memcpy(new_pe->pnet_name, pnet_name, SMC_MAX_PNETID_LEN);
-	strncpy(new_pe->ib_name, ib_name, IB_DEVICE_NAME_MAX);
+	strscpy(new_pe->ib_name, ib_name);

It is worth to mention that caching ib_name is wrong as IB/core provides
IB device rename functionality.

In our case we hit this code path where we pass *PCI_ID*
as the *ib_name* using *smc_pnet* tool(smc_pnet -a <pnet_name> -D
<PCI_ID>). I believe PCI_ID will not change, so caching it here is fine.

If I remember, you are reporting that cached ib_name through netlink much later.

The caching itself is not an issue, but incorrect reported name can be seen as
a wrong thing to do.

In what case we can see this incorrect reported name, could you please
elaborate.

Did you open net/smc/smc_pnet.c?

Yes, I have gone through it focusing on *ib_name* usage.

Everything that uses ib_name in that file is incorrect.

From glance look:
1. smc_pnet_find_ib() returns completely random results if device is
renamed in parallel.

I agree. Currently we are *not* handling the change of IB device names &
when that happens the cached *ib_name* doesn't match anymore with the
changed ib_name. We are looking into this internally.