[libvirt] [RFC][PATCH] Revision for message payload encoding error when adding a large mount of virtio disks

[Richard W.M. Jones]

On Thu, Apr 19, 2012 at 03:04:09PM +0200, Michal Privoznik wrote:
> On 19.04.2012 14:45, Richard W.M. Jones wrote:
> > On Thu, Apr 19, 2012 at 02:25:16PM +0800, Chen Hanxiao wrote:
> >>   * This is an arbitrary limit designed to stop the decoder from trying
> >>   * to allocate unbounded amounts of memory when fed with a bad message.
> >>   */
> >> -const REMOTE_STRING_MAX = 65536;
> >> +const REMOTE_STRING_MAX = 80000;
> > 
> > Can this limit be changed?  I thought it would break existing clients
> > or servers.
> > 
> > Rich.
> > 
> 
> Yes & no. There are 4 possibilities:
> 
> - old both server & client: long string get dropped at server side and
> "unable to encode string/payload" error is thrown.
> 
> - old server & new client: if server wants to send long string it's the
> previous case; client will successfully retransmit message to the daemon
> where it gets later dropped because of limit violation.
> 
> - new server & old client: see previous case
> 
> - new server & new client: nothing gets broken, everything works.
> 
> The only problem is with these gimme-list-of-* APIs. Because here you'll
> get only partial result (first N entries - based on RPC limit).
> 
> Thus, changing this limit is okay.

If we're going to change it, I say change it to something much bigger.

The original limit was very conservative, and was based on some
assumptions about wanting to keep buffers on the stack which is no
longer true in modern libvirt code.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/