[libvirt] [PATCH v3 4/4] qemu-config: Add new -add-fd command line option

[Corey Bryant]

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