On Wed, Jan 4, 2012 at 9:05 PM, Hefty, Sean <[email protected]> wrote: >> 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 ? > > The kernel operation is different, since it relies on callbacks. When the > kernel ib_destroy_cq() > returns, we are guaranteed that the completion handler > (ib_uverbs_comp_handler) is not executing > and will not be called. After destroying the kernel cq, > ib_uverbs_destroy_cq() will remove all > references to the destroyed cq from the event list.
Sorry if I wasn't clear enough, but I was referring to the case where the kernel completion handler gets invoked after ib_uverbs_destroy_cq() has started but before that function has invoked ib_destroy_cq(). More in general - assuming that completion notifications have been enabled - I'm wondering whether it is possible to shut down a queue pair without triggering a race condition if that queue pair hasn't been transitioned to the reset or error state first. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
