On 2026/10/02 19:27, Andrey Drobyshev wrote:
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?
Yes, that is the case I had in mind: management supplies two distinct
FDs referring to the same open file. I agree that this is an invalid
configuration. My concern is that rejecting the second device should not
reset the first device's backend.
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.
A per-vhost_dev ownership flag sounds reasonable.
Regards,
Akihiko Odaki
