On Tue, Feb 26, 2019 at 02:44:54PM +0200, Shamir Rabinovitch wrote: > @@ -797,7 +803,13 @@ void uverbs_close_fd(struct file *f) > * write lock here, or we have a kernel bug. > */ > WARN_ON(uverbs_try_lock_object(uobj, UVERBS_LOOKUP_WRITE)); > - uverbs_destroy_uobject(uobj, RDMA_REMOVE_CLOSE); > + /* > + * send NULL here because attrs bundle are only sent down from > + * idr create/destroy path to pass the driver's context along > + * the call. here there is no such need for driver's context. > + * see call to rdma_udata_to_drv_context. > + */ > + uverbs_destroy_uobject(uobj, RDMA_REMOVE_CLOSE, NULL); This is not a good precedent.. Maybe we should create an on-stack attrs with just the context initialized? > @@ -857,12 +869,15 @@ static int __uverbs_cleanup_ufile(struct ib_uverbs_file *ufile, > * other threads (which might still use the FDs) chance to run. > */ > list_for_each_entry_safe(obj, next_obj, &ufile->uobjects, list) { > + struct uverbs_attr_bundle attrs = { > + .context = obj->context, > + .ufile = obj->context->ufile }; Like this And pull the struct out of the list please struct uverbs_attr_bundle attrs = { .ufile = obj->context->ufile }; list_for_each_entry_safe(obj, next_obj, &ufile->uobjects, list) { attrs.context = obj->context; Jason