On Fri, Apr 20, 2018 at 12:37:08PM +0200, Borislav Petkov wrote:
> Vitezslav reported a case where the
>
> "Timeout during microcode update!"
>
> panic would hit. After a deeper look, it turned out that his .config had
> CONFIG_HOTPLUG_CPU disabled which practically made save_mc_for_early() a
> no-op.
>
> When that happened, the discovered microcode patch wasn't saved into our
> cache and the late loading path wouldn't find any.
>
> This, then, lead to early exit from __reload_late() and thus CPUs
> waiting until the timeout is reached, leading to the panic.
>
> In hindsight, I should've made that function not return before the
> post-synchronization. Oh well, I know better now...
>
> Reported-by: Vitezslav Samel <vitezs...@samel.cz>
Tested-by: Vitezslav Samel <vitezs...@samel.cz>
> Signed-off-by: Borislav Petkov <b...@suse.de>
> Cc: Ashok Raj <ashok....@intel.com>
> Cc: <sta...@vger.kernel.org>
> Fixes: bb8c13d61a62 ("x86/microcode: Fix CPU synchronization routine")
> Link: http://lkml.kernel.org/r/20180418081140.ga2...@pc11.op.pod.cz
> ---
> arch/x86/kernel/cpu/microcode/core.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/microcode/core.c
> b/arch/x86/kernel/cpu/microcode/core.c
> index 10c4fc2c91f8..77e201301528 100644
> --- a/arch/x86/kernel/cpu/microcode/core.c
> +++ b/arch/x86/kernel/cpu/microcode/core.c
> @@ -564,14 +564,12 @@ static int __reload_late(void *info)
> apply_microcode_local(&err);
> spin_unlock(&update_lock);
>
> + /* siblings return UCODE_OK because their engine got updated already */
> if (err > UCODE_NFOUND) {
> pr_warn("Error reloading microcode on CPU %d\n", cpu);
> - return -1;
> - /* siblings return UCODE_OK because their engine got updated already */
> + ret = -1;
> } else if (err == UCODE_UPDATED || err == UCODE_OK) {
> ret = 1;
> - } else {
> - return ret;
> }
>
> /*
> --
> 2.13.0
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB
> 21284 (AG Nürnberg)
> --
