Re: [libvirt] [RFC][PATCH] Revision for message payload encoding error when adding a large mount of virtio disks
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