On Thu, Apr 24, 2025 at 04:26:32PM +0200, Felix Huettner via Devel wrote:
In case of a host that has a large number of cpus offline the count of host cpus and the last bit set in the virHostCPUGetOnlineBitmap might diverge significantly. This can e.g. be the case when disabling smt via /sys/devices/system/cpu/smt/control.
On the host this looks like: ``` $ cat /sys/devices/system/cpu/present 0-255 $ cat /sys/devices/system/cpu/online 0-127 ```
However in this case virBitmapToData previously only allocated 16 bytes for the output bitmap. This is becase the last set bit is on the 15th byte.
Users of virHostCPUGetMap however rely on the "cpumap" containing enough space for all existing cpus (so they would expect 32 bytes in this case). E.g. cmdNodeCpuMap relies on this for its output. It will then actually read 32 bytes from the start of the "cpumap" address where in this case the last 16 of these bytes are uninitialized.
This manifests itself in flapping outputs of "virsh nodecpumap --pretty" like: ``` $ virsh nodecpumap --pretty CPUs present: 256 CPUs online: 128 CPU map: 0-127,192,194,202
$ virsh nodecpumap --pretty CPUs present: 256 CPUs online: 128 CPU map: 0-127,192,194,197
$ virsh nodecpumap --pretty CPUs present: 256 CPUs online: 128 CPU map: 0-127,192,194,196-197 ```
This in turn potentially causes users of this data to report wrong cpu counts.
Note that this only seems to happen with at least 256 physical cpus where at least 128 are offline.
We fix this by preallocating the expected bitmap size.
Signed-off-by: Felix Huettner <felix.huettner@stackit.cloud>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com> Sorry for such a long delay, I noticed this almost out of nowhere. I also somehow lost your mail from Cc when I reposted this with tests here: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/VDYW5...