Lines Matching refs:destroy
26 void (*destroy)(struct iommufd_object *obj);
46 * interact with lockdep, however on destroy we have to sleep. This
47 * means if we have to destroy an object while holding a get on another
58 * in the xarray and visible to other threads we can't reliably destroy
77 * to reliably destroy a single object. Thus all APIs that are creating objects
102 * Abort an object that has been fully initialized and needs destroy, but has
111 iommufd_object_ops[obj->type].destroy(obj);
134 * object is held by the xarray. The caller must call ops destroy().
173 * The caller holds a users refcount and wants to destroy the object. Returns
196 * If there is a bug and we couldn't destroy the object then we did put
203 iommufd_object_ops[obj->type].destroy(obj);
215 iommufd_object_ops[obj->type].destroy(obj);
252 * to destroy them in a depth first manner. Leaf objects will reduce the
268 iommufd_object_ops[obj->type].destroy(obj);
307 struct iommu_destroy destroy;
477 .destroy = iommufd_access_destroy_object,
480 .destroy = iommufd_device_destroy,
483 .destroy = iommufd_ioas_destroy,
486 .destroy = iommufd_hw_pagetable_destroy,
491 .destroy = iommufd_selftest_destroy,