On Mon, Jan 2, 2012 at 4:39 PM, Hefty, Sean <sean.he...@intel.com> wrote: >> If I understood correctly, when ibv_get_cq_event returns, it holds some sort >> of lock over the completion queue, which is >> ibv_destroy_cq, so that: >> 1) When ibv_destroy_cq returns, I am certain that there is no thread running >> somewhere between ibv_get_cq_event and >> ibv_req_notify_cq > > ibv_destroy_cq will block until all outstanding references on the cq have > been released. > The intent is to protect the user from ibv_get_cq_event from returning a >reference to a cq > that is being destroyed from another thread, which could result in a crash in > the user's code.
I've just had a look at the kernel code that implements all this (uverbs_cmd.c and uverbs_main.c). I haven't found any precautions against ib_uverbs_comp_handler() accessing *uobj after ib_uverbs_destroy_cq() has invoked put_uobj(uobj). Did I miss something ? Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html