User level code can be run by root. It can access QP1 and bypass your 
nice API.
Also you ignore current kernel implementations that exist and already 
perform QP1 access via the SA client code in the kernel.

Sean Hefty wrote:
> Eitan Zahavi wrote:
>   
>> The point is not the fact you need to layer. But you can not enforce ref 
>> counting by adding a top layer everybody can bypass.
>> It simply breaks on the first client that goes directly to the lower level.
>> Do you have a solution for this problem?
>> The layer you need to add is BELOW the current interface not ABOVE it.
>>     
>
> I disagree that there's an issue here.  Should we push the snooping down into 
> ib_post_send()?  Into each driver's post_send()?
>   
No you do not need to sniff post_send.  Just QP1 calls.
> We're trusting kernel clients to call the right interfaces.  If we want to 
> start 
> worrying about kernel clients trying to bypass layers, there's nothing that 
> prevents some client from allocating QP0 or 1 for itself (provided that it 
> gets 
> loaded first), snooping MADs and modifying their contents, redirecting 
> requests, 
> registering with the MAD layer to receive MADs of all types, sending MADs out 
> other QPs, etc.
>   
No you are forcing every kernel client out there to do another unneeded 
migration to the new API and still not protect it correctly against 
multicast disconnects.
> We should focus on coming up with the right architecture.  And the 
> functionality 
> that needs to reference count when to send join/leave requests to the SA is 
> above whatever functionality is needed to actually send the MAD.
>
> - Sean
>
> _______________________________________________
> openib-general mailing list
> openib-general@openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>   


_______________________________________________
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to