Hi Dmitry, You're right, thanks for catching this. bo->created is set synchronously in virtio_gpu_cmd_resource_create_blob(), so the unmap/unref completion chain (cmd_unref_cb -> cleanup_object) releases everything once the host acks. The leak I described does not exist - please drop the patch.
Sorry for the noise. Regards, Henry Dmitry Osipenko <[email protected]> 于2026年10月11日周日 04:19写道： > > On 10/10/26 11:10, Henry Martin wrote: > > virtio_gpu_resource_create_blob_ioctl() -> verify_blob() validates > > blob flags, memory type, context and alignment, but never checks > > VIRTGPU_BLOB_FLAG_USE_MAPPABLE against vgdev->has_host_visible. > > > > For blob_mem == VIRTGPU_BLOB_MEM_HOST3D the blob is created via > > virtio_gpu_vram_create(), and on a device without host-visible > > memory (plain virtio-gpu-pci,blob=on with no hostmem) the failure > > comes too late: the GEM object has been allocated, a host resource > > id taken and the create_blob command issued when > > virtio_gpu_vram_map() returns -EINVAL, and the cleanup calls > > virtio_gpu_vram_free(), which is a no-op while bo->created is still > > false (the host response has not been processed yet). Every such > > virtio_gpu_cmd_resource_create_blob() is invoked before > virtio_gpu_vram_map() in virtio_gpu_vram_create(), hence bo->created is > always true, how come it's false? > > -- > Best regards, > Dmitry
