On Tue, Aug 10, 2010 at 04:17:56PM -0600, Eric Blake wrote: > On 08/10/2010 04:01 PM, Daniel Veillard wrote: > > On Tue, Aug 10, 2010 at 03:44:37PM -0600, Eric Blake wrote: > >> https://bugzilla.redhat.com/622515 - When hot-unplugging CPUs, > >> libvirt failed to start a guest that had been pinned to CPUs that > >> were still online, because it was failing to read status from > >> unrelated offline CPUs. > > > > Argh, yes that's a nasty problem ! > > > > > > ACK, that looks fine ! > > > > thanks ! > > Thanks for the review. I'm squashing this in before applying, based on > an IRC comment by Dave Allan that 1024 is an awfully big stack > allocation when we know that the value will fit in an int. > > diff --git i/src/nodeinfo.c w/src/nodeinfo.c > index 2a20679..59e0163 100644 > --- i/src/nodeinfo.c > +++ w/src/nodeinfo.c > @@ -48,6 +48,7 @@ > #include "logging.h" > #include "virterror_internal.h" > #include "count-one-bits.h" > +#include "intprops.h" > > > #define VIR_FROM_THIS VIR_FROM_NONE > @@ -72,7 +73,7 @@ static int get_cpu_value(unsigned int cpu, const char > *file, bool missing_ok) > { > char *path; > FILE *pathfp; > - char value_str[1024]; > + char value_str[INT_BUFSIZE_BOUND(int)]; > char *tmp; > int value = -1; Whoops I didn't catch that ! Actually I wonder if we could catch sequences like \[[0-9]..[0-9]+\] in make syntax-check, maybe this could make sure we always dynamically allocate such large buffers. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list