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

[Corey Bryant]

On 10/18/2012 10:29 AM, Corey Bryant wrote:
>
>
> On 10/17/2012 10: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".
>>
>
> I'd also say "then don't do that".  Or maybe "why are you doing that?".
> But I'm not opposed to closing a corner case if it's not cluttering the
> code base.
>
>>> Hmm, this makes me wonder if I can do something crazy like:
>>>
>>> qemu-kvm -add-fd fd=4,set=1 -qmp /dev/fdset/1
>>>
>>> to open a monitor on the fd I just passed in?
>>
>> I think so. At least on my side it was intended to allow this.
>>
>>> And what if so, what then
>>> happens on that monitor if I request that fdset 1 be removed?
>>
>> The same as with block devices: The fd stays open until the monitor
>> connection is closed. A closed monitor also triggers fd garbage
>> collection, so at this point the original fd would be closed (well,
>> assuming that you had only one monitor).
>>
>> Kevin
>>
>
> True, but I think in this case we care more about the dup'd fd staying
> open than the fd in the fdset.  Remember that qemu_open() dups the fd
> from the fd set.  So assuming the open/close of the QMP fd occurs in
> qemu_open()/qemu_close(), the QMP fd would be a dup of the fd that was
> added to the fd set.  So if remove-fd removed the fd from the fdset, or
> it removed the entire fdset, the QMP fd would remain open until
> qemu_close() was called.  I'll try this out today to make sure but I
> don't think this is an issue.
>

After digging into this some more it appears to be a non issue.  Only 
qemu_open() and qemu_close() deal with fdsets.  The QMP fd is created 
with qemu_socket(), not qemu_open(), so it doesn't deal with fdsets. 
The ensuing bind() call that specifies the path ends up failing with 
ENOENT because the actual path "/dev/fdset/1" doesn't exist:

bind(unix:/dev/fdset/1): No such file or directory

-- 
Regards,
Corey Bryant