On 10/17/2012 08:02 AM, Kevin Wolf wrote:
Am 17.10.2012 06:16, schrieb Eric Blake:
> I'm still seeing the corner case of:
>
> qemu-kvm -add-fd fd=3,set=1 -add-fd fd=4,set=2 4<&-
>
> where the dup(3) will populate fd 4 prior to the point where we get to
> process the -add-fd fd=4 command to notice that the user started
> qemu-kvm with fd 4 closed, and thus qemu will silently proceed to use
> the wrong fd.
>
> On the other hand, I'm not sure if that corner case is worth worrying
> about, or if we just chalk it up to user stupidity (aka libvirt
> programmer stupidity) if they did something like that (most likely,
> because the management app forgot to clear FD_CLOEXEC before exec()ing
> qemu-kvm).
If you specify an FD number that isn't actually open when qemu is
stared, you can get any FD that qemu opens internally. I think the
correct answer to this problem is "then don't do that".
Overnight, I realized we do have one potential safety valve: we are
guaranteed that any fd inherited by the exec() of qemu-kvm has
FD_CLOEXEC clear, and we also strive to have qemu open/dup all of its
internal fds with FD_CLOEXEC set. Therefore, it may be worth a sanity
check of fcntl(F_GETFD) to see if FD_CLOEXEC is set, and if so, the user
must have failed to pass in the fd, and we are now looking at a qemu
internal fd, and should therefore report failure. But I'm not sure if
it's worth the extra code.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org