On Fri, May 18, 2018 at 11:01:32AM -0700, Roland Dreier wrote: > >> 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. I'm assuming those are somehow handled today, as Sean says that was on his mind when he designed it... But I haven't had time to really look. I'm assuming somehow the CM callbacks are synchronized with the CMA internal state so the concurrency is ok.. Otherwise this thing is already hopelessly busted, right? > 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? try_lock is just closer to what we have today so it is less likely to cause unexpected problems. It is already the case that calling the routines out of sequence and unsynchronized most often fails, not waits, so continuing that path and closing the race seems 'safest' only because I don't want to audit everything :) Jason -- 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
