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
next prev parent reply other threads:[~2024-11-06 9:24 UTC|newest]
Thread overview: 25+ 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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).