netdev - Re: [PATCH RFC] RDMA/core: Handle ARPHRD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZH++hitKpvcFC/hQ@nvidia.com>
Date: Tue, 6 Jun 2023 20:17:26 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Chuck Lever III <chuck.lever@...cle.com>
Cc: Chuck Lever <cel@...nel.org>, linux-rdma <linux-rdma@...r.kernel.org>,
	Bernard Metzler <BMT@...ich.ibm.com>, Tom Talpey <tom@...pey.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH RFC] RDMA/core: Handle ARPHRD_NONE devices

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@...dia.com> wrote:
> > 
> > On Fri, Jun 02, 2023 at 03:24:30PM -0400, Chuck Lever wrote:
> >> From: Chuck Lever <chuck.lever@...cle.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. addr_handler() just has to do the right thing with it.
> >> 
> >> Suggested-by: Jason Gunthorpe <jgg@...dia.com>
> >> Signed-off-by: Chuck Lever <chuck.lever@...cle.com>
> >> ---
> >> 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