Received: by 10.192.165.148 with SMTP id m20csp91786imm; Fri, 20 Apr 2018 03:38:34 -0700 (PDT) X-Google-Smtp-Source: AIpwx48Uqkz3EHfRpzkFH57EB0tivnf8zVLs50H2XUlBLhv9JpBTtQBoVzOpuu8ayWW3l+lJm0/+ X-Received: by 10.101.101.66 with SMTP id a2mr8272935pgw.223.1524220714153; Fri, 20 Apr 2018 03:38:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524220714; cv=none; d=google.com; s=arc-20160816; b=u5veAVM6UxFQh/nAYah/+cSBugktg+lNR0n8zLej9u+p7Gp3JtD2lYEHAUw4W8xZ8w rQU5+NURPw0vxlmuzvGPAkhlayv8Re+AbnRQKIvDSpLTDBBkELSx02xznSMm3LtrF2cL heb+RIxJxz807xFuVOINZTqvZ/O/rB6I5KSASrO2pfrZK7TeR/TqGoEpSUW0uI5Ju3Js 6DPoXtaFqYhKfKQrOXOczRay21blFQgXxhiKa8dJkR+zCHka37xzyBZADrNhTn4XwgG9 ezilJ1ebaPYA0mlyS4e6ECw8ZCJoqfB4dJO1IfVo2RAOoXfB3FRtPtGd48u906HBV6u5 cseA== 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:message-id:subject:cc:to:from:date :arc-authentication-results; bh=uVPH4+lYR2umKpWCLNQJ3hySNnXFciHJ5UnposFjOWs=; b=tg05NZllbUzaCVtcPpbEYIiqxWoCDMrPaNirEjZ9Rk0OIy4zFRGZvFd2ZxNdqBeox0 3P2k5yAii56Qt0RhIZiIwl8NQCKvwdZ5kFT9xRdLvnXej9LkQ1m+MpGSXNVo0GMlqpFh 6Ojm8kWJQ3HIyIlnddFLgIs6ofyq1A4a+7GTjzOXVzml4L3x58RnmfkR5imeT0GIf9ia 9jIBTEBMbAvB7WJ83ngvtRcPEXTjjT48vki/QHFqlrcskb3ecn/xOrK5XrqZXDqd5vgL Zep2cUfzK0mnqa1DEqww+YXeXGhgsQOHU3FTXwanERGSyHgVBpX4DIWieEWbI15ibHGk 9P6g== 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 j4si3858644pgs.544.2018.04.20.03.38.19; Fri, 20 Apr 2018 03:38:34 -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 S1754570AbeDTKhN (ORCPT + 99 others); Fri, 20 Apr 2018 06:37:13 -0400 Received: from mx2.suse.de ([195.135.220.15]:35705 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754486AbeDTKhL (ORCPT ); Fri, 20 Apr 2018 06:37:11 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 6AC09ABC9; Fri, 20 Apr 2018 10:37:10 +0000 (UTC) Date: Fri, 20 Apr 2018 12:37:08 +0200 From: Borislav Petkov To: Vitezslav Samel , "Raj, Ashok" Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, x86-ml Subject: [PATCH 2/2] x86/microcode: Do not exit early from __reload_late() Message-ID: <20180420103708.GE13977@pd.tnic> References: <20180419053531.GA2224@pc11.op.pod.cz> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180420103242.GB13977@pd.tnic> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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) --