From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1cVelL-0006T3-JY for kexec@lists.infradead.org; Mon, 23 Jan 2017 13:34:25 +0000 Subject: Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic References: <1485158511-22374-1-git-send-email-xlpang@redhat.com> <20170123125157.u2kefedwpvgcdyfo@pd.tnic> From: Xunlei Pang Message-ID: <588606B9.3070604@redhat.com> Date: Mon, 23 Jan 2017 21:35:53 +0800 MIME-Version: 1.0 In-Reply-To: <20170123125157.u2kefedwpvgcdyfo@pd.tnic> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: xlpang@redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Borislav Petkov , Xunlei Pang Cc: Prarit Bhargava , Kiyoshi Ueda , Tony Luck , x86@kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Ingo Molnar , Junichi Nomura , Naoya Horiguchi , Dave Young On 01/23/2017 at 08:51 PM, Borislav Petkov wrote: > On Mon, Jan 23, 2017 at 04:01:51PM +0800, Xunlei Pang wrote: >> We met an issue for kdump: after kdump kernel boots up, >> and there comes a broadcasted mce in first kernel, the > How does that even happen? > > Lemme try to understand this correctly: the first kernel gets an > MCE, kdump starts and boots a *whole* kernel and *then* you get the > broadcasted MCE? I have real hard time believing that. > > What happened to the approach of clearing CR4.MCE before loading the > kdump kernel, in native_machine_shutdown() or wherever does the kdump > gets loaded... > One possible timing sequence would be: 1st kernel running on multiple cpus panicked then the crash dump code starts the crash dump code stops the others cpus except the crashing one 2nd kernel boots up on the crash cpu with "nr_cpus=1" some broadcasted mce comes on some cpu amongst the other cpus(not the crashing cpu) the other cpus enter old mce handler of 1st kernel, while crash cpu enters new mce handler of 2nd kernel the old mce handler of 1st kernel will timeout and panic due to mce syncrhonization under default setting Regards, Xunlei _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751129AbdAWNeC (ORCPT ); Mon, 23 Jan 2017 08:34:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48234 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750723AbdAWNeB (ORCPT ); Mon, 23 Jan 2017 08:34:01 -0500 Reply-To: xlpang@redhat.com Subject: Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic References: <1485158511-22374-1-git-send-email-xlpang@redhat.com> <20170123125157.u2kefedwpvgcdyfo@pd.tnic> To: Borislav Petkov , Xunlei Pang Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, Tony Luck , Ingo Molnar , Dave Young , Prarit Bhargava , Junichi Nomura , Kiyoshi Ueda , Naoya Horiguchi From: Xunlei Pang Message-ID: <588606B9.3070604@redhat.com> Date: Mon, 23 Jan 2017 21:35:53 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20170123125157.u2kefedwpvgcdyfo@pd.tnic> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 23 Jan 2017 13:34:01 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/23/2017 at 08:51 PM, Borislav Petkov wrote: > On Mon, Jan 23, 2017 at 04:01:51PM +0800, Xunlei Pang wrote: >> We met an issue for kdump: after kdump kernel boots up, >> and there comes a broadcasted mce in first kernel, the > How does that even happen? > > Lemme try to understand this correctly: the first kernel gets an > MCE, kdump starts and boots a *whole* kernel and *then* you get the > broadcasted MCE? I have real hard time believing that. > > What happened to the approach of clearing CR4.MCE before loading the > kdump kernel, in native_machine_shutdown() or wherever does the kdump > gets loaded... > One possible timing sequence would be: 1st kernel running on multiple cpus panicked then the crash dump code starts the crash dump code stops the others cpus except the crashing one 2nd kernel boots up on the crash cpu with "nr_cpus=1" some broadcasted mce comes on some cpu amongst the other cpus(not the crashing cpu) the other cpus enter old mce handler of 1st kernel, while crash cpu enters new mce handler of 2nd kernel the old mce handler of 1st kernel will timeout and panic due to mce syncrhonization under default setting Regards, Xunlei