From patchwork Tue Dec 15 09:46:53 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Borislav Petkov X-Patchwork-Id: 7852961 Return-Path: X-Original-To: patchwork-linux-nvdimm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 633869F387 for ; Tue, 15 Dec 2015 09:47:04 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 902E02028D for ; Tue, 15 Dec 2015 09:47:03 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8AA8520357 for ; Tue, 15 Dec 2015 09:47:02 +0000 (UTC) Received: from ml01.vlan14.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 601411A2230; Tue, 15 Dec 2015 01:47:02 -0800 (PST) X-Original-To: linux-nvdimm@ml01.01.org Delivered-To: linux-nvdimm@ml01.01.org Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:120:8448::d00d]) by ml01.01.org (Postfix) with ESMTP id 3402A1A222F for ; Tue, 15 Dec 2015 01:47:01 -0800 (PST) X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Uyo4jip82xGu; Tue, 15 Dec 2015 10:46:59 +0100 (CET) Received: from pd.tnic (p54895B5F.dip0.t-ipconnect.de [84.137.91.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 2E38F1DA2A4; Tue, 15 Dec 2015 10:46:59 +0100 (CET) Received: by pd.tnic (Postfix, from userid 1000) id EDBFB16015A; Tue, 15 Dec 2015 10:46:53 +0100 (CET) Date: Tue, 15 Dec 2015 10:46:53 +0100 From: Borislav Petkov To: "Luck, Tony" Subject: Re: [PATCHV2 1/3] x86, ras: Add new infrastructure for machine check fixup tables Message-ID: <20151215094653.GA25973@pd.tnic> References: <456153d09e85f2f139020a051caed3ca8f8fca73.1449861203.git.tony.luck@intel.com> <20151212101142.GA3867@pd.tnic> <20151215010059.GA17353@agluck-desk.sc.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20151215010059.GA17353@agluck-desk.sc.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: linux-nvdimm@ml01.01.org, x86@kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar , linux-mm@kvack.org, Andy Lutomirski , Andrew Morton X-BeenThere: linux-nvdimm@lists.01.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Linux-nvdimm developer list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Dec 14, 2015 at 05:00:59PM -0800, Luck, Tony wrote: > Not sure what the "whatnot" would be though. Making it depend on > X86_MCE should keep it out of the tiny configurations. By the time > you have MCE support, this seems like a pretty small incremental > change. Ok, so it is called CONFIG_LIBNVDIMM. Do you see a use case for this stuff except on machines with NVDIMM hw? CONFIG_LIBNVDIMM can select it but on !NVDIMM systems you don't really need it enabled. > Is there some cpp magic to use an #ifdef inside a multi-line macro like this? > Impact of not having the #ifdef is two extra symbols (the start/stop ones) > in the symbol table of the final binary. If that's unacceptable I can fall > back to an earlier unpublished version that had separate EXCEPTION_TABLE and > MCEXCEPTION_TABLE macros with both invoked in the x86 vmlinux.lds.S file. I think what is more important is that this should be in the x86-specific linker script, not in the generic one. And yes, we should strive to be clean and not pullute the kernel image with symbols which are unused, i.e. when CONFIG_MCE_KERNEL_RECOVERY is not enabled. This below seems to build ok here, ontop of yours. It could be a MCEXCEPTION_TABLE macro, as you say: Index: b/include/asm-generic/vmlinux.lds.h =================================================================== --- a/include/asm-generic/vmlinux.lds.h 2015-12-15 10:17:25.568046033 +0100 +++ b/include/asm-generic/vmlinux.lds.h 2015-12-15 10:07:06.064034490 +0100 @@ -484,12 +484,6 @@ *(__ex_table) \ VMLINUX_SYMBOL(__stop___ex_table) = .; \ } \ - . = ALIGN(align); \ - __mcex_table : AT(ADDR(__mcex_table) - LOAD_OFFSET) { \ - VMLINUX_SYMBOL(__start___mcex_table) = .; \ - *(__mcex_table) \ - VMLINUX_SYMBOL(__stop___mcex_table) = .; \ - } /* * Init task Index: b/arch/x86/kernel/vmlinux.lds.S =================================================================== --- a/arch/x86/kernel/vmlinux.lds.S 2015-12-14 11:38:58.188150070 +0100 +++ b/arch/x86/kernel/vmlinux.lds.S 2015-12-15 10:09:04.624036699 +0100 @@ -110,7 +110,17 @@ SECTIONS NOTES :text :note - EXCEPTION_TABLE(16) :text = 0x9090 + EXCEPTION_TABLE(16) + +#ifdef CONFIG_MCE_KERNEL_RECOVERY + . = ALIGN(16); + __mcex_table : AT(ADDR(__mcex_table) - LOAD_OFFSET) { + VMLINUX_SYMBOL(__start___mcex_table) = .; + *(__mcex_table) + VMLINUX_SYMBOL(__stop___mcex_table) = .; + } +#endif + :text = 0x9090 #if defined(CONFIG_DEBUG_RODATA) /* .text should occupy whole number of pages */