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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

On 06/20/2012 07:31 AM, Corey Bryant wrote:

> 
> It sounds like the flow would be:
> 'pass-fd drive-virtio1' of O_RDONLY fd --> guest gets fd 21

No -f, so qemu errors out if an fd named 'drive-virtio1' already exists;
otherwise it succeeds, and returns the fd assigned by SCM_RIGHTS as well
as adding the name to its internal list.

> 'pass-fd -f drive-virtio1' of O_WRONLY fd --> guest gets fd 21?

-f says to fail if 'drive-virtio1' does not already exist in the
internal list.  Otherwise, this is a reopen attempt, and the fd passed
in by SCM_RIGHTS (let's assume it is 23 at this time) is then passed
through dup2() to overwrite the fd already associated with
'drive-virtio1' (21 in this case), then the SCM_RIGHTS fd (23) is
closed.  In this way, the name 'drive-virtio1' remains associated with
fd 21, but we have reopened it with different mode.  At this point, code
that wants to reopen /dev/fd/21 with a new mode will see the new
permissions on the reassigned fd.  And yes, it means that libvirt would
not be allowed to call 'closefd drive-virtio1' until the block device
for drive-virtio1 is no longer around, whether or not the /dev/fd/nn
reuses the fd as-is or whether it dup()s the fd to something else (say
22) for use by the block device.

> 
> But I'm not clear as to how you would retain file descriptor 21 in the
> guest when using 'pass-fd -f drive-virtio1'.  The fd is created as a
> result of passing via SCM_RIGHTS, which assigns the next available fd.
> We don't have control over what fd is assigned, do we?

The use of -f says that 'pass-fd' uses dup2() to reuse an existing fd.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]