On Mon, Jun 12, 2017 at 05:32:28PM +0200, Michal Suchanek wrote:
> There is weird mix of logic in lscpu-dmi.c which sometimes returns 0 and
> sometimes -1 on error. Since most checks are if (rc) goto done; this
> bails out early on error skipping some detection methods. Further, in
> lscpu.c all following detections are guarder by if(hyper) so returnning
> -1 causes all following methods to be skipped. The hyper value is used
> as array index so -1 is out of bounds.
Yes, that's bug.
> Some users observe that they are running under hypervisor and this is
> not detected so it is probably good idea to just try everything.
>
> On the other hand, on some versions of Linux on arm64 reading /dev/mem
> causes kernel oops killing lscpu. If it is desirable for lscpu to work
> on these broken kernels an additional ifdef is required.
We read /sys if possible, and it should be good enough for the current
arm64 kernel (I guess).
> @@ -200,7 +200,7 @@ static int hypervisor_decode_sysfw(void)
> struct stat st;
>
> if (stat(sys_fw_dmi_tables, &st))
> - return -1;
> + return HYPER_NONE;
>
> return hypervisor_from_dmi_table(0, st.st_size, st.st_size / 4,
> sys_fw_dmi_tables);
Not applied.
I don't think this is correct. We need to differentiate between
1/ DMI not in /sys (rc == -1)
2/ DMI available, but nothing detected (rc == HYPER_NONE)
For the 1/ we need to try /dev/mem.
I did some changes to the code to make it more robust. Now
read_hypervisor_dmi() does not return -1 at all.
Please, test it. Thanks!
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
