Re: [PATCH WIP 28/43] IB/core: Introduce new fast registration API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/27/2015 12:14 PM, Jason Gunthorpe wrote:
On Sun, Jul 26, 2015 at 12:45:10PM +0300, Sagi Grimberg wrote:
On 7/23/2015 9:51 PM, Jason Gunthorpe wrote:
On Thu, Jul 23, 2015 at 07:47:14PM +0300, Sagi Grimberg wrote:

So we force ULPs to think about what they are doing properly, and we
get a chance to actually force lkey to be local use only for IB.
The lkey/rkey decision is passed in the fastreg post_send().
That is too late to check the access flags.
Why? the access permissions are kept in the mr context?
Sure, one could do if (key == mr->lkey) .. check lkey flags in the
post, but that seems silly considering we want the post inlined..
Why should we check the lkey/rkey access flags in the post?
Eh? It was your idea..

I just want to check the access flags and force lkey's to not have
ACCESS_REMOTE set without complaining loudly.

To do that you need to know if the mr is a lkey/rkey, and you need to
know the flags.

I can move it to the post interface if it makes more sense.
the access is kind of out of place in the mapping routine anyway...
All the dma routines have an access equivalent during map, I don't
think it is out of place..

To my mind, the map is the point where the MR should crystallize into
an rkey or lkey MR, not at the post.
I'm not sure I understand why the lkey/rkey should be set at the map
routine. To me, it seems more natural to map_mr_sg and then either
register the lkey or the rkey.
We need to check the access flags to put a stop to this remote access
lkey security problem. That means we need to label every MR as a lkey
or rkey MR.

No more MR's can be both nonsense.

Well technically an MR with REMOTE_WRITE also has LOCAL_WRITE set. So you are proposing the core disallow a ULP from using the lkey for this type of MR? Say in a RECV sge?



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



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux