>> We would still need to serialize between CM callbacks and UCMA calling into >> CMA, or at least audit that there are no races there. > > If the design of this was that the caller is responsible for all > serialization then I think the try_lock scheme I outlined before is > the right approach. Putting the locking internal to the functions also > protects agains busted kernel ULPs. > > I guess anthing that isn't already serializing is busted, and > hopefully that is a smaller list... I don't quite understand your reply. I was pointing out a problem with the "call is responsible for all serialization" idea. The problem is that the CM will call into the CMA when incoming CM messages are received, and the consumer of the CMA API has no way to control when this happens. I don't see a way to avoid a messy mix of internal and external locking. What is the advantage of try_lock vs just locking? Can we just say that each id_priv can only be accessed by a single execution context at any given time? - R. -- 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
