On Thu, Mar 22, 2018 at 09:30:37PM +0000, Parav Pandit wrote: > flush_workqueue() will force to execute all the work items for all > pending entries, all must have to completed. Those pending delayed > entries are unrelated to this work item/request in progress, and if > they are large number of entries having 1 sec timeout, > flush_workqueue() might take long. OK then > So one rdma_destroy_id will wait for other requests to be completed, > which I think we should avoid. I looked at this for a bit.. I really don't like how this code works. The idea that rdma_destroy_id() doesn't fence the callback is a bad design, but doesn't apparently cause any bug I can see. I also can't understand why the rdma_addr_client nonsense should exist, it seems to be rolled into the idea that cancel doesn't actually cancel. :( So lets just use the one line patch and save the rest for some other day.. 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
