Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands

[Avi Kivity]

On 07/08/2009 09:21 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
> > On 07/08/2009 09:08 PM, Anthony Liguori wrote:
> > > Avi Kivity wrote:
> > > > I'd prefer the communication layer to queue fds and getfd to 
> > > > dequeue them.
> > >
> > > How many do you queue?  The correct answer is one, btw ;-)
> >
> > You queue as many as you receive, and you dequeue as many getfd 
> > commands as you get.
>
> Then someone can connect to the monitor and consume an arbitrary 
> number of fds?  I'd be very concerned about the potential to leak fds 
> within QEMU from a poorly written client.  Seems like a very easy 
> mistake to make.

Well, that's intrinsic to the getfd command.  We could limit it by 
saying we support a set number of fds, or even give them fixed names.

> > Nothing prevents the client from sending two getfd commands in a 
> > single packet.  We can either support it or start writing detailed 
> > documentation and handle the bug reports when people don't read it.
>
> What would a client do that would result in this happening?  It's 
> really a contrived example when you think about it pragmatically (at 
> least given today's monitor).

I am in fact thinking of tomorrow's monitor.  If indeed we follow an rpc 
model, it should be quite easy to have multiple threads (each doing an 
unrelated task) each issuing a series of commands and processing the 
replies.  There would be a lock protecting the socket, but there would 
be no reason to limit the number of outstanding commands.  I think 
that's a perfectly reasonable way to write a client.

If the client is written in a high level language it's also reasonable 
that some buffering would take place and you'd see a single packet 
containing multiple commands, or a command split into multiple packets.  
Therefore I'd like to avoid any assumptions in this area.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.