On Fri, 17 Apr 2015 10:13:25 +0200, Jean Delvare wrote: > In function dmi_present(), dmi_walk_early() calls dmi_table(), which > calls dmi_decode(), which ultimately calls dmi_save_uuid(). This last > function makes a decision based on the value of global variable > dmi_ver. The problem is that this variable is set right _after_ > dmi_walk_early() returns. So dmi_save_uuid() always sees dmi_ver == 0 > regardless of the actual version implemented. > > This causes /sys/class/dmi/id/product_uuid to always use the old > ordering even on systems implementing DMI/SMBIOS 2.6 or later, which > should use the new ordering. > > This is broken since kernel v3.8 for legacy DMI implementations and > since kernel v3.10 for SMBIOS 2 implementations. SMBIOS 3 > implementations with the 64-bit entry point are not affected. > > The first breakage does not matter much as in practice legacy DMI > implementations are always for versions older than 2.6, which is when > the UUID ordering changed. The second breakage is more problematic as > it affects the vast majority of x86 systems manufactured since 2009. > > Signed-off-by: Jean Delvare <[email protected]> > Fixes: 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from > SMBIOS if it exists") > Fixes: 79bae42d51a5 ("dmi_scan: refactor dmi_scan_machine(), > {smbios,dmi}_present()") > Acked-by: Zhenzhong Duan <[email protected]> > Cc: Ben Hutchings <[email protected]> > Cc: Artem Savkov <[email protected]> > Cc: Ivan Khoronzhuk <[email protected]> > Cc: Matt Fleming <[email protected]> > Cc: [email protected] [v3.10+] > --- > Changes since v1: > * Rebased on torvalds/linux/master.
Bah, scratch that, I have come up with a different approach that will make backporting this fix easier. Sorry for the noise. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
