On Thu, Mar 15, 2018 at 12:01:05AM +0000, Parav Pandit wrote: > > So we can call something like ib_send_cm_req from userspace and race it with > > the above code, and corrupt av. Not sure why ibv_send_cm_req doesn't hold the > > spinlock while calling cm_init_av_by_path, probably should. > AV initialization is blocking call. Well, I found call sites that call cm_init_av_by_path under a spinlock :( > > I think all the places that write to the av need to update the av under the spin > > lock. Looks like the best way to do it above is to write a temporary av to the > > stack and then re-acquire the lock and copy it to the priv ?? All places that write > > to av need checking.. > This is done for non-LAP message processing path in internal series > under review to you, Leon, Mark for a while now. Since you are > asking this more high level question, I like to ask what is the > state of [1]? I'm not sure what [1] is? You mean Leons' ucm deletion patch? > [1] is not submitted as RFC, so I presume that is strong need to > drop this module. And if we are dropping ucm module out of the > kernel than all the APIs which are only called by UCM module should > go out too. This is a good point, yes. Leon? > And LAP message are part of it. So like to know whether to invest > more energy in making this code right, which has almost no users? I wouldn't do anything related exclusively to ucm, yes. But.. this patch is still complicated, it is hard to see if all the readers are safe or not.. 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
