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

[Chen HanXiao]

>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.
>> > 
>> 
>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/
>

It would be beter to change current REMOTE_STRING_MAX to a bigger number.
But VIR_NET_MESSAGE_MAX limited the buffer for XDR stream as 4*REMOTE_STRING_MAX in
current libvirt.
So could the REMOTE_STRING_MAX change as half as the VIR_NET_MESSAGE_MAX?
----
-const REMOTE_STRING_MAX = 65536;
+const REMOTE_STRING_MAX = 131072;	//twice as many as before
----

It's accuracy to allocate the buffer size 4 times as much as message size.
According to the real message, most of them are strings. So I think 
REMOTE_STRING_MAX with half size of VIR_NET_MESSAGE_MAX is not 
a bad choice.
I test this change on my machine, it seems to work fine.

If Michal's dynamically allocating buffer function finished, we could change this 
limit to a bigger one.

--------------
Regards

Chen HanXiao