Received: by 10.192.165.148 with SMTP id m20csp430627imm; Fri, 20 Apr 2018 09:02:14 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/jITjT1Ry1WczuPRQjRjqzkUW0ENw6//2QvEgEFLPF2LPuULToP1ZWWzHE+KKiKU/IH3OW X-Received: by 10.101.98.138 with SMTP id f10mr3591739pgv.6.1524240134609; Fri, 20 Apr 2018 09:02:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524240134; cv=none; d=google.com; s=arc-20160816; b=1Gi4MCI60x6KxySiOv+SQJ6U/cD8BhpLX46n0RtbvGEBbdLCc/UeWMNrEn79obdEI4 BiX+wxbdatF+dHx8qS77KGvE7ZM698/5Kq0qXaPrgSx4H6CImVQcEYyPZILuSSOkO9MY SOD7D1mYUckg3cc6e14A6WoxRKJT01f9PePsftodxMahC9J2jFnu6fJMHwi5ibMpxuGP km5E6RtfVOEEf+XahE6oiyQAE04imUC8LAKouMCUtk9D7WW29Ovhgcg4uc2+scTOBx5u K/Wj3DxcqCc8iAJi8wxBOtHaLuOf28MPsD+5LL6Dca8GfS56qIOmGgIKvDACNPI3rnyL eBgg== 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-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=Y3rfnBCnnoiAZkzs6iRjbfvcQjz2eRvuqnFTtVINiyw=; b=cAYGFkenPtirh+r7imMXGK8e0vOtYykuZa0pSpIrbYPZOqmCFmSeQEkZVSRJmeQf56 X2kxbNGnJ/r8JXOcv5h7qK9fKiCu3JIxuR/TfCziQQr7WMwCJu152O7mvLMHvWOC/m/2 KKJWhoQH4sO4aazZoaUILHc0t56uFvHdw5HsEDwnv+PEUTc2DslzEQovPvzXvYFOkmmN I+3ezzQ1/JTIBTkUrDZF3LPmLzEWiB5jsPSGyeUq3MitXv0g/tLyu5qUvwzWMWSqWDrQ Qy1GLegfh9E0oVZA7ha58znwCunjYvEsuHiEiEOiF+8UOKU+fobfUaH1rHmrOHDH2Qdm 1TXw== 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 n3-v6si5809687plb.147.2018.04.20.09.01.59; Fri, 20 Apr 2018 09:02:14 -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 S1755995AbeDTQAc (ORCPT + 99 others); Fri, 20 Apr 2018 12:00:32 -0400 Received: from mga09.intel.com ([134.134.136.24]:9051 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755903AbeDTQAT (ORCPT ); Fri, 20 Apr 2018 12:00:19 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2018 09:00:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,302,1520924400"; d="scan'208";a="193082415" Received: from araj-mobl1.jf.intel.com ([10.7.201.28]) by orsmga004.jf.intel.com with ESMTP; 20 Apr 2018 09:00:18 -0700 Date: Fri, 20 Apr 2018 09:00:18 -0700 From: "Raj, Ashok" To: Borislav Petkov Cc: Vitezslav Samel , 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: <20180420160017.GB9792@araj-mobl1.jf.intel.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20180420103708.GE13977@pd.tnic> User-Agent: Mutt/1.9.1 (2017-09-22) 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 > Signed-off-by: Borislav Petkov Tested-by: Ashok Raj > Cc: Ashok Raj > Cc: > Fixes: bb8c13d61a62 ("x86/microcode: Fix CPU synchronization routine") > Link: http://lkml.kernel.org/r/20180418081140.GA2439@pc11.op.pod.cz > ---