lkml.org 
[lkml]   [2013]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.
--


\
 
 \ /
  Last update: 2013-07-24 22:41    [W:0.130 / U:2.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site