From: Jason Gunthorpe <jgg@nvidia.com>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Chuck Lever <cel@kernel.org>,
linux-rdma <linux-rdma@vger.kernel.org>,
Tom Talpey <tom@talpey.com>,
"BMT@zurich.ibm.com" <BMT@zurich.ibm.com>
Subject: Re: [PATCH v3 4/4] RDMA/cma: Avoid GID lookups on iWARP devices
Date: Fri, 23 Jun 2023 14:12:03 -0300 [thread overview]
Message-ID: <ZJXSY8GeA7H04L1U@nvidia.com> (raw)
In-Reply-To: <F9569E5B-A89B-4683-9A51-CF9C53686358@oracle.com>
On Fri, Jun 23, 2023 at 05:02:23PM +0000, Chuck Lever III wrote:
>
>
> > On Jun 22, 2023, at 11:13 AM, Jason Gunthorpe <jgg@nvidia.com> wrote:
> >
> > On Wed, Jun 14, 2023 at 10:00:59AM -0400, Chuck Lever wrote:
> >> From: Chuck Lever <chuck.lever@oracle.com>
> >>
> >> We would like to enable the use of siw on top of a VPN that is
> >> constructed and managed via a tun device. That hasn't worked up
> >> until now because ARPHRD_NONE devices (such as tun devices) have
> >> no GID for the RDMA/core to look up.
> >>
> >> But it turns out that the egress device has already been picked for
> >> us -- no GID is necessary. addr_handler() just has to do the right
> >> thing with it.
> >>
> >> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> >> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> >> ---
> >> drivers/infiniband/core/cma.c | 13 +++++++++++++
> >> 1 file changed, 13 insertions(+)
> >>
> >> diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
> >> index a1756ed1faa1..50b8da2c4720 100644
> >> --- a/drivers/infiniband/core/cma.c
> >> +++ b/drivers/infiniband/core/cma.c
> >> @@ -700,6 +700,19 @@ cma_validate_port(struct ib_device *device, u32 port,
> >> if ((dev_type != ARPHRD_INFINIBAND) && rdma_protocol_ib(device, port))
> >> goto out;
> >>
> >> + if (rdma_protocol_iwarp(device, port)) {
> >> + sgid_attr = rdma_get_gid_attr(device, port, 0);
> >> + if (IS_ERR(sgid_attr))
> >> + goto out;
> >> +
> >> + /* XXX: I don't think this is RCU-safe, but does it need to be? */
> >
> > Maybe for subtle reasons related to iwarp it is safe, but it should
> > make a lockdep splat since you are not holding rcu?
> >
> > Remove the comment and do a rcu_lock/unlock around this and the deref
>
> Done, v4 posted.
>
> The reason I was unsure:
>
> CC drivers/infiniband/core/roce_gid_mgmt.o
> CHECK /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c
> /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c:292:23: warning: incorrect type in assignment (different address spaces)
> /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c:292:23: expected struct net_device [noderef] __rcu *[addressable] ndev
> /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c:292:23: got struct net_device *ndev
> /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c:386:48: warning: incorrect type in initializer (different address spaces)
> /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c:386:48: expected struct net_device [noderef] __rcu *ndev
> /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c:386:48: got struct net_device *ndev
> /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c:811:48: warning: incorrect type in argument 2 (different address spaces)
> /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c:811:48: expected void *filter_cookie
> /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c:811:48: got struct net_device [noderef] __rcu *ndev
> /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c:814:31: warning: incorrect type in argument 1 (different address spaces)
> /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c:814:31: expected struct net_device *dev
> /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c:814:31: got struct net_device [noderef] __rcu *ndev
> /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c:851:31: warning: incorrect type in assignment (different address spaces)
> /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c:851:31: expected struct net_device [noderef] __rcu *ndev
> /home/cel/src/linux/linux/drivers/infiniband/core/roce_gid_mgmt.c:851:31: got struct net_device *ndev
Ah, nobody has cleaned that stuff :\
Jason
next prev parent reply other threads:[~2023-06-23 17:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-14 14:00 [PATCH v3 0/4] Handle ARPHRD_NONE devices for siw Chuck Lever
2023-06-14 14:00 ` [PATCH v3 1/4] RDMA/siw: Fabricate a GID on tun and loopback devices Chuck Lever
2023-06-15 8:18 ` Bernard Metzler
2023-06-23 18:25 ` Tom Talpey
2023-06-14 14:00 ` [PATCH v3 2/4] RDMA/core: Set gid_attr.ndev for iWARP devices Chuck Lever
2023-06-23 18:37 ` Tom Talpey
2023-06-23 18:40 ` Chuck Lever III
2023-06-23 18:46 ` Tom Talpey
2023-06-14 14:00 ` [PATCH v3 3/4] RDMA/cma: Deduplicate error flow in cma_validate_port() Chuck Lever
2023-06-14 14:00 ` [PATCH v3 4/4] RDMA/cma: Avoid GID lookups on iWARP devices Chuck Lever
2023-06-22 15:13 ` Jason Gunthorpe
2023-06-23 17:02 ` Chuck Lever III
2023-06-23 17:12 ` Jason Gunthorpe [this message]
2023-06-15 11:59 ` [PATCH v3 0/4] Handle ARPHRD_NONE devices for siw Zhu Yanjun
2023-06-15 13:28 ` Chuck Lever III
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=ZJXSY8GeA7H04L1U@nvidia.com \
--to=jgg@nvidia.com \
--cc=BMT@zurich.ibm.com \
--cc=cel@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=linux-rdma@vger.kernel.org \
--cc=tom@talpey.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.