[openib-general] [RFC] [PATCH 2/7] ib_multicast 2.6.20: add ib_multicast module to track join requests from the same port

[Eitan Zahavi]

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 at openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>