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.