[libvirt] [PATCH v3 0/5] file descriptor passing using pass-fd
Eric Blake
eblake at redhat.com
Wed Jun 20 14:53:51 UTC 2012
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 at redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120620/12f06885/attachment-0001.sig>
More information about the libvir-list
mailing list