On Tue, Jun 06, 2023 at 08:15:36PM +0000, Chuck Lever III wrote:
>
>
> > On Jun 6, 2023, at 11:48 AM, Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:
> >
> > On Fri, Jun 02, 2023 at 03:24:30PM -0400, Chuck Lever wrote:
> >> From: Chuck Lever <chuck.lever@xxxxxxxxxx>
> >>
> >> 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. addr_handler() just has to do the right thing with it.
> >>
> >> Suggested-by: Jason Gunthorpe <jgg@xxxxxxxxxx>
> >> Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx>
> >> ---
> >> drivers/infiniband/core/cma.c | 4 ++++
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
> >> index 56e568fcd32b..3351dc5afa17 100644
> >> --- a/drivers/infiniband/core/cma.c
> >> +++ b/drivers/infiniband/core/cma.c
> >> @@ -704,11 +704,15 @@ cma_validate_port(struct ib_device *device, u32 port,
> >> ndev = dev_get_by_index(dev_addr->net, bound_if_index);
> >> if (!ndev)
> >> return ERR_PTR(-ENODEV);
> >> + } else if (dev_type == ARPHRD_NONE) {
> >> + sgid_attr = rdma_get_gid_attr(device, port, 0);
> >
> > It seems believable, should it be locked to iwarp devices?
> >
> > More broadly, should iwarp devices just always do this and skip all
> > the rest of it?
> >
> > I think it also has to check that the returned netdev in the sgid_attr
> > matches the egress netdev selected?
>
> Both @ndev and sgid_attr.ndev are NULL here.
The nedev to check is the dev_addr->bound_dev_if, that represents the netdev
It is some iwarp mistake that the sgid attr's don't have proper
netdevs, that is newer than iwarp so it never got updated.
So, maybe it is too hard to fix for this, and maybe we can just assume
it all has to be right
Jason
