It makes no sense to fail the whole getting command if there is parameter unsupported by the kernel. This patch fixes it by
s/parameter/a parameter/
omitting the unsupported parameter for getMemoryParameters.
And For setMemoryParameters, this checks if there is unsupported
s/For/for/ s/is/is an/
parameter up front of the setting, and just returns failure if not all parameters are supported.
- * filled with parameter information, which might be less but will - * not exceed the input value. + * Get all node memory parameters (parameter unsupported by OS will be
s/parameter/parameters/
#ifdef __linux__ static int -nodeSetMemoryParameterValue(const char *field, - virTypedParameterPtr param) +nodeSetMemoryParameterValue(virTypedParameterPtr param) { char *path = NULL; char *strval = NULL; int ret = -1; int rc = -1;
+ char *field = strchr(param->field, '_'); + field++;
This site should be safe (we only get here if we got past earlier filters), but...
+static bool +nodeMemoryParametersIsAllSupported(virTypedParameterPtr params, + int nparams) +{ + char *path = NULL; + int i; + + for (i = 0; i < nparams; i++) { + virTypedParameterPtr param = ¶ms[i]; + + char *field = strchr(param->field, '_'); + field++;
Are we guaranteed that field is non-NULL, or could the user pass us a param->field name that doesn't contain '_', in which case we are doing bad dereferencing? That is, since this is the earlier filter that makes the rest of the code safe, I think you need to be prepared for the user to pass unexpected strings, and fail if field is NULL at this point. ACK with that fixed.