From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758244AbcBCWxq (ORCPT ); Wed, 3 Feb 2016 17:53:46 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:37894 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750828AbcBCWxg (ORCPT ); Wed, 3 Feb 2016 17:53:36 -0500 Date: Wed, 3 Feb 2016 22:53:33 +0000 From: Matt Fleming To: Dave Young Cc: linux-efi@vger.kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/efi: skip bgrt init for kexec reboot Message-ID: <20160203225333.GA31246@codeblueprint.co.uk> References: <20160127112044.GA2961@dhcp-128-65.nay.redhat.com> <20160203214200.GA15110@dhcp-128-65.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160203214200.GA15110@dhcp-128-65.nay.redhat.com> User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 04 Feb, at 05:42:00AM, Dave Young wrote: > > On 01/27/16 at 07:20pm, Dave Young wrote: > > For kexec reboot the bgrt image address could contains random data because > > we have freed boot service areas in 1st kernel boot phase. One possible > > result is kmalloc fail in efi_bgrt_init due to large random image size. > > > > So change efi_late_init to avoid efi_bgrt_init in case kexec boot. > > > > Signed-off-by: Dave Young > > --- > > arch/x86/platform/efi/efi.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > --- linux-x86.orig/arch/x86/platform/efi/efi.c > > +++ linux-x86/arch/x86/platform/efi/efi.c > > @@ -531,7 +531,8 @@ void __init efi_init(void) > > > > void __init efi_late_init(void) > > { > > - efi_bgrt_init(); > > + if (!efi_setup) > > + efi_bgrt_init(); > > } > > > > void __init efi_set_executable(efi_memory_desc_t *md, bool executable) > > Matt, opinions about this patch? Yeah, I'm not happy seeing efi_setup escaping into even more places, nor am I happy to see more code paths introduced where kexec boot is special-cased. I'll reply with more details tomorrow.