On Sun, Jun 17, 2018 at 12:59:55PM +0300, Leon Romanovsky wrote:
> +void uverbs_cleanup_ucontext(struct ib_ucontext *ucontext, bool device_removed)
> +{
> /*
> * Waits for all remove_commit and alloc_commit to finish. Logically, We
> * want to hold this forever as the context is going to be destroyed,
> * but we'll release it since it causes a "held lock freed" BUG message.
> */
> down_write(&ucontext->cleanup_rwsem);
> + while (!list_empty(&ucontext->uobjects))
> + if (__uverbs_cleanup_ucontext(ucontext, RDMA_REMOVE_DESTROY))
> + /* No entry was cleaned-up successfully during this iteration */
> + break;
No, this isn't right, it must remain REMOVE or CLOSE here. The enum is
a signal to the driver what is going on. DESTROY is only for user
triggered destroy called in a user context.
There needs to be some kind of guarenteed return from the driver that
destroy is failing due to elevated refcounts, and not some other
reason.. This is just checking for any ret?
> - while (!list_empty(&ucontext->uobjects)) {
> - struct ib_uobject *obj, *next_obj;
> - unsigned int next_order = UINT_MAX;
> + if (!list_empty(&ucontext->uobjects))
> + __uverbs_cleanup_ucontext(ucontext, device_removed ?
> + RDMA_REMOVE_DRIVER_REMOVE : RDMA_REMOVE_CLOSE);
Failure to cleanup is a driver bug, and should be reported with
WARN_ON. This is also mis using the remove enum, CLOSE is not a
'bigger hammer'
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
