>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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list