Re: [Qemu-devel] [PATCH v3 0/5] file descriptor passing using pass-fd

[Kevin Wolf <kwolf@redhat.com>]

Am 19.06.2012 18:14, schrieb Eric Blake:
>> Maybe it's better to have a monitor command that just prepares a reopen
>> and means "for the next reopen of /dev/fd/42, the passed FD will have
>> the right flags (if it hasn't, the reopen will fail)". We can use dup2()
>> to keep the "name" stable.
> 
> Indeed, having one additional up-front command in the pass-fd/closefd
> family might make this easier.  But how would it work reliably?
> Remember, the current proposal is:
> 
> libvirt opens backing file O_RDONLY, and calls 'pass-fd name'
> qemu returns 21
> libvirt tells qemu to hotplug a drive with /dev/fd/21 as backing file
> qemu dup()s 21, and proceeds to use fd 22 for all its real work
> libvirt calls 'closefd name', to avoid the leak on fd 21

Right, I didn't consider that we really use a dup()ed fd.

I'm not completely clear about when libvirt should call closefd, and
what the lifetime of fd 21 is. If I'm not mistaken, the reason for using
dup() and requiring an explicit closefd was that qemu can reopen the
file multiple times, for example for probing, but it's basically the
same with commit. If so, nothing else must become fd 21 while the image
is still in use as qemu might decide to reopen.

This might mean that libvirt should only closefd the file when it
becomes unused (like after hot unplug); or that qemu must keep it open
internally even after closefd as long as the block device is still in use.

Kevin