Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

From: Jason Gunthorpe <jgg@ziepe.ca>
To: "Håkon Bugge" <haakon.bugge@oracle.com>
Cc: Hal Rosenstock <hal@dev.mellanox.co.il>,
	Doug Ledford <dledford@redhat.com>,
	Don Hiatt <don.hiatt@intel.com>, Ira Weiny <ira.weiny@intel.com>,
	Sean Hefty <sean.hefty@intel.com>,
	OFED mailing list <linux-rdma@vger.kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys
Date: Mon, 14 May 2018 15:04:08 -0600	[thread overview]
Message-ID: <20180514210408.GO21531@ziepe.ca> (raw)
In-Reply-To: <23B160D2-6631-42A6-8A4D-644E90E8A704@oracle.com>

On Fri, May 11, 2018 at 12:55:00PM +0200, Håkon Bugge wrote:
> > I'll check upstream OpenSM when I get a chance to see if same problem
> > exists. Oracle OpenSM forked from upstream long time ago and not sure
> > how similar the path record code is. There were various impacts for the
> > shared port virtualization (for CX-3) in terms of adding the ability to
> > allow both pkeys.
> 
> I just had a chat with Line H. here in Oracle. She confirms that Oracle’s SM and the upstream one act similar in this matter.
> 
> Further, using shared port virtualization, OpenSM will adhere to the
> physical ports only, and doesn’t even know the PKey assignments to
> the VFs assigned the VMs.

Yes, but that isn't the point. If the VM receives a PR with a pkey
that is not found in the VM's table then it should not even send a CM
REQ in the first place.

Jason