Re: [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd

[Kevin Wolf <kwolf@redhat.com>]

Am 05.07.2012 19:00, schrieb Eric Blake:
> On 07/05/2012 10:35 AM, Corey Bryant wrote:
>> 1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with
>> refcount of 0; fd=4's in-use flag is turned on
>> 2. client calls 'device-add' with /dev/fdset/1 as the backing filename,
>> so qemu_open() increments the refcount of fdset1 to 1
>> 3. client calls 'remove-fd fdset=1 fd=4', so qemu marks fd=4 as no
>> longer in-use by the monitor, and is left open because it is in use by
>> the block device (refcount is 1)
>> 4. client crashes, so all tracked fds are visited; fd=4 is not in-use
>> but refcount is 1 so it is not closed
> 5. client re-establishes QMP connection, so all tracked fds are visited.
>  What happens to the fd=4 in-use flag?
> 
> ...but what are the semantics here?
> 
> If we _always_ turn the in-use flag back on, then that says that even
> though libvirt successfully asked to close the fd, the reconnection
> means that libvirt once again has to ask to close things.
> 
> If we _never_ turn the in-use flag back on, then we've broken the first
> case above where we want an in-use fd to come back into use after a crash.
> 
> Maybe that argues for two flags per fd: an in-use flag (there is
> currently a monitor connection that can manipulate the fd, either
> because it passed in the fd or because it reconnected) and a removed
> flag (a monitor called remove-fd, and no longer wants to know about the
> fd, even if it crashes and reconnects).  

I was in fact just going to suggest a removed flag as well, however
combined with including the monitor connections in the refcount instead
of an additional flag. This would also allow to have (the currently
mostly hypothetical case of) multiple QMP monitors without interesting
things happening.

Maybe I'm missing some point that the inuse flag would allow and
including monitors in the refcount doesn't. Is there one?

Kevin