On Tue, 17 Oct 2023 at 04:26, Albert Esteve <aest...@redhat.com> wrote: > > Hi! > > Thanks for the patch, and sorry for not noticing the flag had already been > assigned. The patch looks good to me!
Hi Albert, I looked at the shared object code for the first time: - There are memory leaks in virtio_add_dmabuf() and virtio_add_vhost_device() when the UUID was added previously. - The hash table is global and there is no spoofing protection, so vhost-user devices can hijack known UUIDs. Is it possible to associate a vhost_dev owner with each shared object and only allow the owner to remove it? - Is there cleanup code that removes shared objects from the hash table when a vhost_dev is destroyed? Otherwise TYPE_VHOST_DEV shared objects are leaked and their stale vhost_dev pointers could be dereferenced. - virtio-dmabuf.h API naming suggests this is a core VirtIODevice API: virtio_free_resources(), virtio_add_vhost_device(), etc rather than an API for VirtioSharedObject. Can the names be made more specific: virtio_dmabuf_*() or virtio_shobj_*() so it's clear these APIs are related to the dmabufs/shared objects? Thanks, Stefan
