On 10/17/2012 11:03 AM, Kevin Wolf wrote:
Am 17.10.2012 17:01, schrieb Eric Blake:
> 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.
Hm, this sounds actually easy enough. I'll leave the decision to Corey,
but I like the idea.
Sure I can add this.
--
Regards,
Corey Bryant