All of lore.kernel.org
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@linux.ibm.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Wenjia Zhang <wenjia@linux.ibm.com>,
	Wen Gu <guwen@linux.alibaba.com>,
	"D. Wythe" <alibuda@linux.alibaba.com>,
	Tony Lu <tonylu@linux.alibaba.com>,
	David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
	linux-s390@vger.kernel.org, Heiko Carstens <hca@linux.ibm.com>,
	Jan Karcher <jaka@linux.ibm.com>,
	Gerd Bayer <gbayer@linux.ibm.com>,
	Alexandra Winter <wintera@linux.ibm.com>,
	Nils Hoppmann <niho@linux.ibm.com>,
	Niklas Schnell <schnelle@linux.ibm.com>,
	Thorsten Winkler <twinkler@linux.ibm.com>,
	Karsten Graul <kgraul@linux.ibm.com>,
	Stefan Raspl <raspl@linux.ibm.com>, Aswin K <aswin@linux.ibm.com>,
	Halil Pasic <pasic@linux.ibm.com>
Subject: Re: [PATCH net] net/smc: Fix lookup of netdev by using ib_device_get_netdev()
Date: Wed, 6 Nov 2024 10:24:39 +0100	[thread overview]
Message-ID: <20241106102439.4ca5effc.pasic@linux.ibm.com> (raw)
In-Reply-To: <20241105112313.GE311159@unreal>

On Tue, 5 Nov 2024 13:23:13 +0200
Leon Romanovsky <leon@kernel.org> wrote:

> On Tue, Nov 05, 2024 at 10:50:45AM +0100, Wenjia Zhang wrote:
> > 
> > 
> > On 27.10.24 21:18, Leon Romanovsky wrote:  
> > > On Fri, Oct 25, 2024 at 09:23:55AM +0200, Wenjia Zhang wrote:  
> > > > Commit c2261dd76b54 ("RDMA/device: Add ib_device_set_netdev() as
> > > > an alternative to get_netdev") introduced an API
> > > > ib_device_get_netdev. The SMC-R variant of the SMC protocol
> > > > continued to use the old API ib_device_ops.get_netdev() to
> > > > lookup netdev.  
> > > 
> > > I would say that calls to ibdev ops from ULPs was never been right
> > > thing to do. The ib_device_set_netdev() was introduced for the
> > > drivers.
> > > 
> > > So the whole commit message is not accurate and better to be
> > > rewritten. 
> > > > As this commit 8d159eb2117b
> > > > ("RDMA/mlx5: Use IB set_netdev and get_netdev functions")
> > > > removed the get_netdev callback from
> > > > mlx5_ib_dev_common_roce_ops, calling ib_device_ops.get_netdev
> > > > didn't work any more at least by using a mlx5 device driver.  
> > > 
> > > It is not a correct statement too. All modern drivers (for last 5
> > > years) don't have that .get_netdev() ops, so it is not mlx5
> > > specific, but another justification to say that SMC-R was doing it
> > > wrong. 
> > > > Thus, using ib_device_set_netdev() now became mandatory.  
> > > 
> > > ib_device_set_netdev() is mandatory for the drivers, it is nothing
> > > to do with ULPs.
> > >   
> > > > 
> > > > Replace ib_device_ops.get_netdev() with ib_device_get_netdev().  
> > > 
> > > It is too late for me to do proper review for today, but I would
> > > say that it is worth to pay attention to multiple dev_put() calls
> > > in the functions around the ib_device_get_netdev().
> > >   
> > > > 
> > > > Fixes: 54903572c23c ("net/smc: allow pnetid-less configuration")
> > > > Fixes: 8d159eb2117b ("RDMA/mlx5: Use IB set_netdev and
> > > > get_netdev functions")  
> > > 
> > > It is not related to this change Fixes line.
> > >   
> > 
> > Hi Leon,
> > 
> > Thank you for the review! I agree that SMC could do better. However,
> > we should fix it and give enough information and reference on the
> > changes, since the code has already existed and didn't work with the
> > old way.   
> 
> The code which you change worked by chance and was wrong from day one.

I absolutely agree with that statement. But please notice that the
commit date of commit c2261dd76b54 ("RDMA/device: Add
ib_device_set_netdev() as an alternative to get_netdev") predates the
commit date of commit 54903572c23c ("net/smc: allow pnetid-less
configuration") only by 9 days. And before commit c2261dd76b54
("RDMA/device: Add ib_device_set_netdev() as an alternative to
get_netdev") there was no 
ib_device_get_netdev() AFAICT.

Maybe the two patches crossed mid air so to say.

> 
> > I can rewrite the commit message.
> > 
> > What about:
> > "
> > The SMC-R variant of the SMC protocol still called
> > ib_device_ops.get_netdev() to lookup netdev. As we used mlx5 device
> > driver to run SMC-R, it failed to find a device, because in mlx5_ib
> > the internal net device management for retrieving net devices was
> > replaced by a common interface ib_device_get_netdev() in commit
> > 8d159eb2117b ("RDMA/mlx5: Use IB set_netdev and get_netdev
> > functions"). Thus, replace ib_device_ops.get_netdev() with
> > ib_device_get_netdev() in SMC. "  
> 
>  The SMC-R variant of the SMC protocol used direct call to
> ib_device_ops.get_netdev() function to lookup netdev. Such direct
> accesses are not correct for any usage outside of RDMA core code. 
> 

I agree, it is not correct since c2261dd76b54 ("RDMA/device: Add
ib_device_set_netdev() as an alternative to get_netdev").

Does fs/smb/server/transport_rdma.c qualify as inside of RDMA core code?
I would guess it is not, and I would not actually mind sending a patch
but I have trouble figuring out the logic behind  commit ecce70cf17d9
("ksmbd: fix missing RDMA-capable flag for IPoIB device in
ksmbd_rdma_capable_netdev()").


>  RDMA subsystem provides ib_device_get_netdev() function that works on
>  all RDMA drivers returns valid netdev with proper locking an reference
>  counting. The commit 8d159eb2117b ("RDMA/mlx5: Use IB set_netdev and
> get_netdev functions") exposed that SMC-R didn't use that function.
> 

I believe the intention was this all along. I think the commit message
was written with the idea that 54903572c23c happened before c2261dd76b54
which is not the case.

>  So update the SMC-R to use proper API,
> 

I believe this is exactly what the patch does! And I agree we need to
improve on the commit message.

Regards,
Halil

  parent reply	other threads:[~2024-11-06  9:24 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-25  7:23 [PATCH net] net/smc: Fix lookup of netdev by using ib_device_get_netdev() Wenjia Zhang
2024-10-25  8:57 ` Halil Pasic
2024-10-25 14:01 ` Simon Horman
2024-10-26  0:42 ` Dust Li
2024-10-27 11:18 ` Wen Gu
2024-10-27 19:28 ` Zhu Yanjun
2024-10-27 20:18 ` Leon Romanovsky
2024-10-27 20:30   ` Leon Romanovsky
2024-11-05  9:50   ` Wenjia Zhang
2024-11-05 11:23     ` Leon Romanovsky
2024-11-05 12:30       ` Wenjia Zhang
2024-11-05 13:39         ` Leon Romanovsky
2024-11-05 14:14           ` Wenjia Zhang
2024-11-06  9:24       ` Halil Pasic [this message]
2024-11-06 13:59         ` Leon Romanovsky
2024-11-07 11:47           ` Halil Pasic
2024-11-07 12:08             ` Leon Romanovsky
2024-11-07 11:56           ` Halil Pasic
2024-11-07 12:13             ` Leon Romanovsky
2024-11-07 23:40             ` Namjae Jeon
2024-11-08 17:59               ` Leon Romanovsky
2024-11-09  5:32                 ` Namjae Jeon
2024-12-13 11:07                 ` Kangjing Huang
2024-12-13 12:15                   ` Leon Romanovsky
2024-12-14  2:33                   ` Namjae Jeon
2024-12-14  6:06                     ` Leon Romanovsky
2024-12-14  8:02                       ` Kangjing Huang
2024-12-19 16:56                         ` Leon Romanovsky
2025-01-07 22:51                           ` Kangjing Huang
2025-01-08  9:31                             ` Leon Romanovsky
2025-01-08 17:27                               ` Tom Talpey
2025-01-08 22:40                                 ` Kangjing Huang
2025-01-09  7:59                                   ` Leon Romanovsky
2025-01-09  8:02                             ` Christoph Hellwig
2025-01-09 10:43                               ` Kangjing Huang
2025-01-09 17:49                                 ` Tom Talpey
2025-01-15  7:17                                   ` Christoph Hellwig
2024-10-29  8:43 ` D. Wythe
2024-10-31 10:01 ` Paolo Abeni
2024-11-05  9:53   ` Wenjia Zhang

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=20241106102439.4ca5effc.pasic@linux.ibm.com \
    --to=pasic@linux.ibm.com \
    --cc=alibuda@linux.alibaba.com \
    --cc=aswin@linux.ibm.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gbayer@linux.ibm.com \
    --cc=guwen@linux.alibaba.com \
    --cc=hca@linux.ibm.com \
    --cc=jaka@linux.ibm.com \
    --cc=kgraul@linux.ibm.com \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=niho@linux.ibm.com \
    --cc=pabeni@redhat.com \
    --cc=raspl@linux.ibm.com \
    --cc=schnelle@linux.ibm.com \
    --cc=tonylu@linux.alibaba.com \
    --cc=twinkler@linux.ibm.com \
    --cc=wenjia@linux.ibm.com \
    --cc=wintera@linux.ibm.com \
    /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.