On 10/1/26 2:04 PM, Akihiko Odaki wrote: > On 2026/10/01 17:25, Andrey Drobyshev wrote: >> vhost_dev_cleanup() closes the backend FD, but that doesn't release the >> device ownership taken with VHOST_SET_OWNER if the same file is open >> elsewhere. That's the case on a CPR target: the source keeps the FD, >> so if the target fails after SET_OWNER, either inside vhost_dev_init() >> or later in its caller, the ownership stays with the target. Once the >> source is resumed it can't take the device back, SET_OWNER fails with >> EBUSY. >> >> Issue VHOST_RESET_OWNER in vhost_dev_cleanup() as the common teardown >> for all those paths. That's safe in any case: the kernel refuses it >> from a non-owner, and an owner is about to close the FD anyway. > > There is one minor counterexample: if a second netdev receives a > duplicate of an already-used vhost-net FD, initialization fails with > EBUSY, but cleanup then resets the first device. > > Regards, > Akihiko Odaki
Hmm, IIUC QEMU itself doesn't dup vhostfd backend FD provided to it by the management. So we're talking about the case when the management (i.e. libvirt) dup'ed vhostfd and provided same backend FD for multiple different devices. Correct? I didn't think of such config cause it's clearly illegal. However I agree we should probably be more error-prone for such a case. So if we want to have this covered, then I guess we'll have to add another flag to 'struct vhost_dev', indicating whether this particular vhost_dev instance currently holds the ownership. That's pretty much what Stefano was suggesting in the previous thread. Thanks, Andrey
