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

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.