On 4/13/2016 11:23 PM, Hefty, Sean wrote: >>>> Former (multicast modifications of fabric) also requires restricting >>>> arbitrary UD QPs as well as QP1 as SA access is QPn (n > 0) <-> QP1. >>> >>> The SA could have an option to ignore all requests that do not originate >> QP1, >>> then protect access to QP1 on the client nodes. >> >> I'm not really sure what we are protecting against here. Is it simply DoS >> against the SA? > > This would protect against a non-privileged QP trying to change multicast or event subscription, for example. Though it could help with DoS, by avoiding the processing associated with requests. Jason's original question was why would you want to leave qp1 open, and I think the answer to that depends on what restrictions could be enforced for qpX: X > 1. Restricting both seem desirable, IMO. > There are no qpX to qpX restrictions. As long as the users that created both QPs have permission to use the PKey in the PKey index they specified then they are free to communicate in any way. -- 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
