On Tue, Jun 26, 2012 at 09:52:51AM -0400, Corey Bryant wrote:
> >So now from a client's POV you'd have a flow like
> >
> > * drive_add "file=/dev/fd/N" FDSET={N}
>
> IIUC then drive_add would loop and pass each fd in the set via SCM_RIGHTS?
Yes, you'd probably use the JSON to tell QEMU exactly
how many FDs you're intending to pass with the command,
and then once the command is received, you'd have N*SCM_RIGHTS
messages sent/received.
> >
> >And in QEMU you'd have something like
> >
> > * handle_monitor_command
> > - recvmsg all FDs, and stash them in a thread local "FDContext"
> > context
> > - invoke monitor command handler
> > - Sees file=/dev/fd/N
> > - Fetch /dev/fd/N from "FDContext"
> > - If success remove /dev/fd/N from "FDContext"
> > - close() all FDs left in "FDContext"
> >
> >The key point with this is that because the FDs are directly
> >associated with a monitor command, QEMU can /guarantee/ that
> >FDs are never leaked, regardless of client behaviour.
>
> Wouldn't this leak fds if libvirt crashed part way through sending
> the set of fds?
No, because you've scoped the FDs to the current monitor instance,
and the current command being processed you know to close all FDs
when the associated command has finished, as well as closing them
all if you see EOF on the monitor socket while in the middle of
receiving a command.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list