From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53647C54EBC for ; Tue, 10 Jan 2023 12:14:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232893AbjAJMOV (ORCPT ); Tue, 10 Jan 2023 07:14:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238177AbjAJMN0 (ORCPT ); Tue, 10 Jan 2023 07:13:26 -0500 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A9F43A0 for ; Tue, 10 Jan 2023 04:11:35 -0800 (PST) Received: from zn.tnic (p5de8e9fe.dip0.t-ipconnect.de [93.232.233.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id F04B81EC04A9; Tue, 10 Jan 2023 13:11:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1673352694; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=ZfOt5HDc34dr/smZxobD5IUZu0DIYXCMGlcbHhVp6Uk=; b=K/ZZSGYc3r17rRW2Q8WTFUmOhY/+8gSzNUfNuRa/IedMQDzOxInAxjMWGsC/6uP3VdVTpT PX29LZ3Qi8l3waD95SnfzK1gUmaUws2UlDoWSlzVTcMT+1S1iRh+UEmeUjUctTQD2+aqYo sU/mgVsBnjdEsR+nmj4NIk7/t7bef6g= Date: Tue, 10 Jan 2023 13:11:29 +0100 From: Borislav Petkov To: Ingo Molnar Cc: Zeng Heng , michael.roth@amd.com, hpa@zytor.com, tglx@linutronix.de, sathyanarayanan.kuppuswamy@linux.intel.com, kirill.shutemov@linux.intel.com, jroedel@suse.de, keescook@chromium.org, mingo@redhat.com, dave.hansen@linux.intel.com, brijesh.singh@amd.com, linux-kernel@vger.kernel.org, x86@kernel.org, liwei391@huawei.com Subject: Re: [PATCH -v2] x86/boot/compressed: Register dummy NMI handler in EFI boot loader, to avoid kdump crashes Message-ID: References: <20230110102745.2514694-1-zengheng4@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 10, 2023 at 01:01:06PM +0100, Ingo Molnar wrote: > From: Zeng Heng > Date: Tue, 10 Jan 2023 18:27:45 +0800 > Subject: [PATCH] x86/boot/compressed: Register dummy NMI handler in EFI boot loader, to avoid kdump crashes > > If kdump is enabled, when using mce_inject to inject errors, EFI Why does "EFI" matter here? Any boot loader would do... > boot loader would decompress & load second kernel for saving the s/&/and/ > vmcore file. > > For normal errors that is fine. Useless sentence. > However, in the MCE case, the panic > CPU that firstly enters into mce_panic() is running within NMI > interrupt context, "#MC context" it is non-maskable but that's not "NMI interrupt context" > and the processor blocks delivery of subsequent > NMIs until the next execution of the IRET instruction. > > When the panic CPU takes long time in the panic processing route, I'm still unclear on the order of events here. It sounds like 1. MCE injected 2. panic 3. kdump gets loaded If that is the case, then I presume the flow is: mce_panic -> panic -> __crash_kexec() Yes? If so, then we should make sure we have *exited* #MC context before calling panic() and not have to add hacks like this one of adding an empty NMI handler. But I'm only speculating as it is hard to make sense of all this text. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette