Messages in this thread | | | Date | Wed, 24 Jul 2013 21:32:50 +0200 | From | Borislav Petkov <> | Subject | Re: [PATCH 5/5] x86, AMD: simplify load_microcode_amd() to fix early microcode loading to no longer access uninitialized per-cpu data |
| |
On Tue, Jul 23, 2013 at 11:06:10PM +0200, Torsten Kaiser wrote: > load_microcode_amd() (and the helper it is using) should not have an > cpu parameter. The microcode loading is not depending on the CPU it is > executed and all the loaded patches will end up in a global list for all > CPUs anyway. > The change from cpu to x86family in load_microcode_amd() now allows to drop > the code messing with cpu_data(cpu) from collect_cpu_info_amd_early(), which > is wrong anyway because at that point the per-cpu cpu_info is not yet setup. > And these values would later be overwritten by smp_store_boot_cpu_info() / > smp_store_cpu_info(). > > Fold the rest of collect_cpu_info_amd_early() into load_ucode_amd_ap(), because its > only used at one place and without the cpuinfo_x86 accesses it was not much left. > > Signed-off-by: Torsten Kaiser <just.for.lkml@googlemail.com>
Btw, this patch is the one that fixes the boot issue on your box, correct?
If so, please put a minimal version of it in the next patch set you're sending right after
[PATCH v2] x86, AMD: Make cpu_has_amd_erratum() use the correct struct cpuinfo_x86 [PATCH 1/5] x86, AMD: fix error path in apply_microcode_amd()
So that all fixes can go in now.
Basically, we need the fixes to be first in the patchset so that they can be applied straight to tip:urgent.
The cleanups/improvements you're doing afterwards could wait then for the next merge window.
Thanks a lot!
-- Regards/Gruss, Boris.
Sent from a fat crate under my desk. Formatting is fine. --
| |