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