On Wed, May 16, 2018 at 08:35:56AM -0700, Roland Dreier wrote: > > Am I missing something? Did it start out OK and just get broken over > > the last decade? > > As far as I can see, the bug is already there in the very first CMA commit > e51060f08a61. > > I'm not sure we can make id_priv state changes transactional - looks like > some of the state may be hard to roll back. Well, if rollback is impossible then it can move forward as well, just the few I looked at appeared to use that pattern.. > And anyway this is just obfuscated locking, except that simultaneous > operations fail rather than wait for each other. Yes, it would be implemented internally with try_lock I think. > fix is just to make access to id_priv exclusive - have every > function take a per-id lock while state is changing, so everything > happens atomically if multiple threads access the same id. Yes, that is where I was driving too as well, but I don't know why this is try and fail with no lock today. Sean? Do you recall? 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
