[libvirt] [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd
coreyb at linux.vnet.ibm.com
Tue Jul 3 18:21:17 UTC 2012
On 07/03/2012 02:00 PM, Eric Blake wrote:
> On 07/03/2012 11:46 AM, Corey Bryant wrote:
>> Yes, I think adding a +1 to the refcount for the monitor makes sense.
>> I'm a bit unsure how to increment the refcount when a monitor reconnects
>> though. Maybe it is as simple as adding a +1 to each fd's refcount when
>> the next QMP monitor connects.
> Or maybe delay a +1 until after a 'query-fds' - it is not until the
> monitor has reconnected and learned what fds it should be aware of that
> incrementing the refcount again makes sense. But that would mean making
> 'query-fds' track whether this is the first call since the monitor
> reconnected, as it shouldn't normally increase refcounts.
This doesn't sound ideal.
> The other alternative is that the monitor never re-increments a
> refcount. Once a monitor disconnects, that fd is lost to the monitor,
> and a reconnected monitor must pass in a new fd to be re-associated with
> the fdset. In other words, the monitor's use of an fd is a one-way
> operation, starting life in use but ending at the first disconnect or
I would vote for this 2nd alternative. As long as we're not introducing
an fd leak. And I don't think we are if we decrement the refcount on
remove-fd or on QMP disconnect.
>>> 1. client calls 'add-fd', qemu is now tracking fd=4 with refcount 1, in
>>> use by monitor, as member of fdset1
>>> 2. client calls 'device-add' with /dev/fdset/1 as the backing filename,
>>> so qemu_open() increments the refcount to 2
>>> 3. client crashes, so all tracked fds are visited; fd=4 had not yet been
>>> passed to 'remove-fd', so qemu decrements refcount to 1, but leaves fd=4
>>> open because it is still in use by the block device
>>> 4. client re-establishes QMP connection, and 'query-fds' lets client
>>> learn about fd=4 still being open as part of fdset1, but also informs
>>> client that fd is not in use by the monitor
>> And in step 4 the QMP connection will increment the refcount +1 for all
>> fds that persisted through the QMP disconnect. (?)
> I'm not sure we need the refcount increment on reconnect. 'query-fds'
> should provide enough information for the new monitor to know what
> fdsets are still in use by qemu, even though they are no longer
> available to 'remove-fd' from the monitor, and if the monitor is worried
> about keeping the fd set alive it can call 'add-fd' to again associate a
> new fd with the set. The lifetime of a set is thus as long as any of
> its associated fds have a non-zero refcount.
This sounds good to me.
And qemu_open will need to make sure the monitor in_use flag is true
before dup'ing an fd.
More information about the libvir-list