[libvirt] [PATCH] esx: Fix nodeGetInfo so cpu model fits inside nodeinfo->model
Commit 6c0d0210cbcd5d647f0d882c07f077d444bc707d changed the behavior of virStr*cpy* functions, so now the nodeGetInfo call fails. Version 4.1.0 (default for Fedora 28) works: Model: Intel Core i7-4500U CPU @ 1.80G Current master tries to write "Intel Core i7-4500U CPU @ 1.80GHz", but the string is bigger than nodeinfo->model (which is a char[32]). So this patch "cuts" the string, and presents the same output from 4.1.0. Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com> --- When testing both qemu and lxc drivers, both return "x86_64", as both call virCapabilitiesGetNodeInfo in order the get all info the "node", but they are a Linux machine. When it comes to ESX, it returns a string from the ESX server, which is same info that I can find in /proc/cpuinfo of my machine (but without the () parts): model name : Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz The question is: should libvirt increase the model size, or just find a better way for ESX to present this info? src/esx/esx_driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c index c2154799fa..03a84d7630 100644 --- a/src/esx/esx_driver.c +++ b/src/esx/esx_driver.c @@ -1317,6 +1317,8 @@ esxNodeGetInfo(virConnectPtr conn, virNodeInfoPtr nodeinfo) ++ptr; } + /* Make sure the string fits in mode */ + dynamicProperty->val->string[sizeof(nodeinfo->model) - 1] = '\0'; if (virStrcpyStatic(nodeinfo->model, dynamicProperty->val->string) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, _("CPU Model %s too long for destination"), -- 2.17.1
On 08/12/2018 01:05 PM, Marcos Paulo de Souza wrote:
Commit 6c0d0210cbcd5d647f0d882c07f077d444bc707d changed the behavior of virStr*cpy* functions, so now the nodeGetInfo call fails. Version 4.1.0 (default for Fedora 28) works:
Model: Intel Core i7-4500U CPU @ 1.80G
Current master tries to write "Intel Core i7-4500U CPU @ 1.80GHz", but the string is bigger than nodeinfo->model (which is a char[32]). So this patch "cuts" the string, and presents the same output from 4.1.0.
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com> ---
When testing both qemu and lxc drivers, both return "x86_64", as both call virCapabilitiesGetNodeInfo in order the get all info the "node", but they are a Linux machine.
When it comes to ESX, it returns a string from the ESX server, which is same info that I can find in /proc/cpuinfo of my machine (but without the () parts): model name : Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz
The question is: should libvirt increase the model size, or just find a better way for ESX to present this info?
We can't do that. It would break ABI. Any app that is linking with libvirt right now expects to see a 32 bytes long string. If we change that to anything bigger we would overwrite the app's memory. Needless to say, XDR would be broken too.
src/esx/esx_driver.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c index c2154799fa..03a84d7630 100644 --- a/src/esx/esx_driver.c +++ b/src/esx/esx_driver.c @@ -1317,6 +1317,8 @@ esxNodeGetInfo(virConnectPtr conn, virNodeInfoPtr nodeinfo) ++ptr; }
+ /* Make sure the string fits in mode */ + dynamicProperty->val->string[sizeof(nodeinfo->model) - 1] = '\0'; if (virStrcpyStatic(nodeinfo->model, dynamicProperty->val->string) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, _("CPU Model %s too long for destination"),
This in fact is the only way to fix the issue IMO. ACKed and pushed. Michal
participants (2)
-
Marcos Paulo de Souza -
Michal Prívozník