netdev - Re: [PATCH v4 for-next 00/12] Add network namespace support in the RDMA-CM

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: <20150603214508.GA14968@obsidianresearch.com>
Date:	Wed, 3 Jun 2015 15:45:08 -0600
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Or Gerlitz <gerlitz.or@...il.com>
Cc:	Doug Ledford <dledford@...hat.com>,
	Haggai Eran <haggaie@...lanox.com>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Liran Liss <liranl@...lanox.com>,
	Guy Shapiro <guysh@...lanox.com>,
	Shachar Raindel <raindel@...lanox.com>,
	Yotam Kenneth <yotamke@...lanox.com>
Subject: Re: [PATCH v4 for-next 00/12] Add network namespace support in the
 RDMA-CM

On Wed, Jun 03, 2015 at 11:07:37PM +0300, Or Gerlitz wrote:
> As Haggai wrote, if we let the using IP address thing to fly up, we have
> support for RDMA in containers using the RDMA-CM at IPoIB environments.
> This will let people test, use, experiment, fix, interact (and even
> production-it when static IP address assignment scheme is used).

Sure, I think we all understand the goal, and you've explained some
reasonable use cases for the child support.

> Later, usage of alias GUIDs for IPoIB RTNL childs would allow to
> remove the IP thing.

How do we remove it? Along with same-guid child support? What is your
idea here?

> > Also, now that this has been brought up, I think you need to make a
> > patch to fix the IPv6 SLAAC breakage this caused. It looks trivial to
> > modify addrconf_ifid_infiniband to return error if the IPoIB child is
> > sharing a guid. It was not good at all to push the child patches
> > forward to 3.6/3.7 if you knew that IPv6 SLAAC was broken by them.
> 
> Till the alias GUID thing is introduced, maybe we can patch
> addrconf_ifid_infiniband to use the QPN value from the device HW
> address to come up with unique IPv6 link local address, agree? where
> you think we can place the 24 bits QPN?

I don't know if that is a good idea, an unstable SLAAC is not in
spirit with the RFCs. The safest bet is to return error and disable
SLAAC completely.

But I'm just guessing here - I'm only feel strongly that something
should be done to address this issue in the existing kernel.

Jason
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html