From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752730AbdBTLKJ (ORCPT ); Mon, 20 Feb 2017 06:10:09 -0500 Received: from mail.skyhub.de ([78.46.96.112]:46774 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752598AbdBTLKI (ORCPT ); Mon, 20 Feb 2017 06:10:08 -0500 Date: Mon, 20 Feb 2017 12:09:41 +0100 From: Borislav Petkov To: 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 Subject: Re: [PATCH v2] x86/mce: Don't participate in rendezvous process once nmi_shootdown_cpus() was made Message-ID: <20170220110941.vwcm3je3e4kkei6o@pd.tnic> References: <1487571037-10821-1-git-send-email-xlpang@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1487571037-10821-1-git-send-email-xlpang@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 20, 2017 at 02:10:37PM +0800, Xunlei Pang wrote: > @@ -1128,8 +1129,9 @@ void do_machine_check(struct pt_regs *regs, long error_code) > */ > int lmce = 1; > > - /* If this CPU is offline, just bail out. */ > - if (cpu_is_offline(smp_processor_id())) { > + /* If nmi shootdown happened or this CPU is offline, just bail out. */ > + if (cpus_shotdown() || I don't like "cpus_shotdown" - it doesn't hint at all that this is special-handling crash/kdump. And more importantly, I want it to be obvious that we do let the crashing CPU into the MCE handler. Why? If we didn't, you will not handle *any* MCE, even a fatal one, during dumping memory so if that dump is corrupted from the MCE, you won't know. And I don't want to be the one staring at the corrupted dump and wondering why I'm seeing what I'm seeing. IOW, if we get a fatal MCE during dumping then we should go and die. This is much better than silently corrupting the dump and not even saying anything about it. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.