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

Reply via email to