Re: [PATCH for-next V1 5/9] IB/core: Add rdma_network_type to wc

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

 



On Wed, Nov 25, 2015 at 8:55 AM, Jason Gunthorpe
<jgunthorpe@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Nov 24, 2015 at 09:07:41PM +0200, Matan Barak wrote:
>
>> IMHO, the user is entitles to choose any valid sgid_index for the
>> interface. Anything he chooses guaranteed to be valid (from security
>> perspective)
>
> No, the namespace patches will have to limit the sgid_indexes that can
> be used with a QP to those that fall within the namespace. This is
> another reason I don't like this approach for the kapi.
>

By saying namespace, do you mean net namespaces?
If so, the gid cache allows to search by net device (and there's a
"custom" search that the user can define a filter function which can
filter by net).
Anyway, I don't think this cache should be used other than a simple database.

>> Why do we need to block users who use ibv_rc_pingpong and chose the
>> GID index correctly by hand?
>
> I'm not really concerned with user space, we are stuck with exporting
> the gid index there.
>

So why do we need to block kernel applications from doing the same
things user-space application can do?

>> > OK. Change the gid cache so only a RDMA CM private API can return
>> > rocev2 gids.
>>
>> So you propose to block verbs applications from using the RoCE v2 GIDs? Why?
>
> Just the kernel consumers, so the in-kernel users are correct.
>

If there are kernel consumers that want to work with verbs directly,
they should use ib_init_ah_from_wc and ib_resolve_eth_dmac (or we can
rename that for other L2 attributes).
The shared code shouldn't be in the cache.

> Jason

Matan
--
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