[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands |
Date: |
Wed, 08 Jul 2009 13:50:37 -0500 |
User-agent: |
Thunderbird 2.0.0.21 (X11/20090320) |
Avi Kivity wrote:
On 07/08/2009 09:21 PM, Anthony Liguori wrote:
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.
So what's the set number and why isn't 1 a reasonable fixed number?
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.
Indeed, I figured as much :-)
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.
You can't just use a lock on the socket for transmit because you have to
deal with partial transmissions and the subsequent queuing. You need a
single queue mechanism shared by all writers and you need writers to
submit the full rpcs so that they can be queued in the proper order.
When we get to the point of the RPC model though, we'll have one monitor
state for each asynchronous message we're processing. I contend that we
only ever want to pass a single fd per command so if we stick with
queueing 1 fd per monitor today, it'll map quite nicely to how we would
handle things in the RPC model.
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.
That misses the point though. We process one command at a time in the
monitor so we only need to buffer one fd at a time. When we start to
process multiple commands at once in the monitor, we'll do so with
multiple monitor states and we'll want to have one fd per monitor state.
Message boundaries really don't matter.
Regards,
Anthony Liguori
- [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands, (continued)
- Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands, Avi Kivity, 2009/07/08
- Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands, Mark McLoughlin, 2009/07/08
- Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands, Avi Kivity, 2009/07/08
- Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands, Anthony Liguori, 2009/07/08
- Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands, Avi Kivity, 2009/07/08
- Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands, Anthony Liguori, 2009/07/08
- Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands, Avi Kivity, 2009/07/08
- Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands,
Anthony Liguori <=
- Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands, Avi Kivity, 2009/07/08
- Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands, Jamie Lokier, 2009/07/10
- Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands, Mark McLoughlin, 2009/07/21
- [Qemu-devel] [PATCH] Make tcp_chr_read() use recvmsg(), Mark McLoughlin, 2009/07/21
- Re: [Qemu-devel] [PATCH] Make tcp_chr_read() use recvmsg(), Blue Swirl, 2009/07/21
- Re: [Qemu-devel] [PATCH] Make tcp_chr_read() use recvmsg(), Jamie Lokier, 2009/07/21
- Re: [Qemu-devel] [PATCH] Make tcp_chr_read() use recvmsg(), Mark McLoughlin, 2009/07/22
- [Qemu-devel] [PATCH 1/5] Make tcp_chr_read() use recvmsg(), Mark McLoughlin, 2009/07/22
- [Qemu-devel] [PATCH 5/5] Add support for fd=name to tap and socket networking, Mark McLoughlin, 2009/07/22
- Re: [Qemu-devel] [PATCH 5/5] Add support for fd=name to tap and socket networking, Mark McLoughlin, 2009/07/23