Received: by 10.192.165.148 with SMTP id m20csp107201imm; Fri, 20 Apr 2018 03:58:28 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+5fdh9HLmCDabXIb5GDAXbrwA59I+EPzIY9zD2tiTxn9wCrizpiZcm4ThF1pN9P2DxJWbF X-Received: by 10.101.96.150 with SMTP id t22mr8212179pgu.4.1524221908283; Fri, 20 Apr 2018 03:58:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524221908; cv=none; d=google.com; s=arc-20160816; b=IzqgRH3jnOMYOtdnH3PnbZAEQQRTc/ii2sWDixb7dLDdpvqsSRqs1JOtseak14rBUC 85kNU2+28vyaxZLlvoXMARwRQC1TkAEWK7QZsFDEcd2r5loM05ZarfI4MSs2ElivlnW7 VYdUPmSEEBzyMhHuU3xNtsj/HDE4WNQwI/pbkJMQcLwghKPI8OFdaNWkZC/b+84Dbr4S EtTfjc41Kfst2OcKeg8X2lTAhRnbwivIGLEDFLEejFKFR16Zw25SCGQlv9gT1i9FNMMT lu01V7oe50l1j21DW439fGYHctQZhIvVaivLQgBQIVHxwqiANUt9DoeZpz0d/2v2gw5j xNmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:mail-followup-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=UlcPcVo2r7x4XMUGSEhs8crUAVZkBtKp5Za1ZGm7bqE=; b=kRh3O7L6l9JrcaHa/nI3EcyFVrPRF0ivCYeqzmM437p9dgU7nGArjYc/A9qeQteqVv 85iWch/0Nw4N2VdSbcyhLueLcmhtUkuxczbjPHUhPZX9wyK7I1OStQQVTAkEZJk9jGcu xcNMC7xMmXUgMC9hirQB8C7Rk7TmldxFeM3GaOJWBfJmNizEHr57E2F7eBS8BQA7XtB3 poH20lhMQiaRPgCNybgcn7d/YH388KXiwOD7iYgE4KdmbZY1WNf2GejMKIDKbytWe7sD Y8S2ZsmjPJK0V9vXXdUhoECjiiFHF2MkgK7bcuxV1IaV0U9q50q44c4qRR9LVFcV12Rm rCuw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f7-v6si4123334plb.285.2018.04.20.03.58.14; Fri, 20 Apr 2018 03:58:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754694AbeDTKym (ORCPT + 99 others); Fri, 20 Apr 2018 06:54:42 -0400 Received: from mail.pod.cz ([213.155.227.146]:57062 "EHLO mail.pod.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754511AbeDTKyk (ORCPT ); Fri, 20 Apr 2018 06:54:40 -0400 Received: by pc11.op.pod.cz (Postfix, from userid 475) id 40SCRM0FCYz71yN; Fri, 20 Apr 2018 12:54:38 +0200 (CEST) Date: Fri, 20 Apr 2018 12:54:38 +0200 From: Vitezslav Samel To: Borislav Petkov Cc: "Raj, Ashok" , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, x86-ml Subject: Re: [PATCH 2/2] x86/microcode: Do not exit early from __reload_late() Message-ID: <20180420105438.GB2257@pc11.op.pod.cz> Mail-Followup-To: Borislav Petkov , "Raj, Ashok" , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, x86-ml References: <20180419104829.GE3896@pd.tnic> <20180419120239.GA2377@pc11.op.pod.cz> <20180419121840.GF3896@pd.tnic> <20180419134627.GA2387@pc11.op.pod.cz> <20180419163734.GB3905@pd.tnic> <20180420062021.GA2253@pc11.op.pod.cz> <20180420095220.GA13977@pd.tnic> <20180420100131.GA14217@pc11.op.pod.cz> <20180420103242.GB13977@pd.tnic> <20180420103708.GE13977@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180420103708.GE13977@pd.tnic> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Tested-by: Vitezslav Samel > Signed-off-by: Borislav Petkov > Cc: Ashok Raj > Cc: > Fixes: bb8c13d61a62 ("x86/microcode: Fix CPU synchronization routine") > Link: http://lkml.kernel.org/r/20180418081140.GA2439@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) > --