Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Young <dyoung@redhat.com>
To: Matt Fleming <matt@codeblueprint.co.uk>
Cc: linux-efi@vger.kernel.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Omar Sandoval <osandov@osandov.com>,
	kernel-team@fb.com
Subject: Re: kexec regression since 4.9 caused by efi
Date: Tue, 21 Mar 2017 15:48:26 +0800	[thread overview]
Message-ID: <20170321074826.GA4571@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <20170320021412.GA3793@dhcp-128-65.nay.redhat.com>

On 03/20/17 at 10:14am, Dave Young wrote:
> On 03/17/17 at 01:32pm, Matt Fleming wrote:
> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> > > 
> > > Matt, I think it should be fine although I think the md type checking in
> > > efi_mem_desc_lookup() is causing confusion and not easy to understand..
> >  
> > Could you make that a separate patch if you think of improvements
> > there?
> 
> Duplicate the lookup function is indeed a little ugly, will do it when I
> have a better idea, we can leave it as is since it works.

Matt, rethinking about this, how about doint something below, not
tested, just seeking for idea and opinons, in this way no need duplicate
a function, but there is an assumption that no overlapped mem ranges in
efi memmap.

Also the case Omar reported is the esrt memory range type is
RUNTIME_DATA, that is a little different with the mem attribute of
RUNTIME which also includes BOOT_DATA which has been set the RUNTIME
attribute, like bgrt in kexec reboot. Should we distinguish the two
cases and give out some warnings or debug info?


---
 arch/x86/platform/efi/quirks.c |    5 +++++
 drivers/firmware/efi/efi.c     |    6 ------
 drivers/firmware/efi/esrt.c    |    7 +++++++
 3 files changed, 12 insertions(+), 6 deletions(-)

--- linux-x86.orig/drivers/firmware/efi/efi.c
+++ linux-x86/drivers/firmware/efi/efi.c
@@ -376,12 +376,6 @@ int __init efi_mem_desc_lookup(u64 phys_
 		u64 size;
 		u64 end;
 
-		if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
-		    md->type != EFI_BOOT_SERVICES_DATA &&
-		    md->type != EFI_RUNTIME_SERVICES_DATA) {
-			continue;
-		}
-
 		size = md->num_pages << EFI_PAGE_SHIFT;
 		end = md->phys_addr + size;
 		if (phys_addr >= md->phys_addr && phys_addr < end) {
--- linux-x86.orig/drivers/firmware/efi/esrt.c
+++ linux-x86/drivers/firmware/efi/esrt.c
@@ -258,6 +258,13 @@ void __init efi_esrt_init(void)
 		return;
 	}
 
+	if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
+	      md->type != EFI_BOOT_SERVICES_DATA &&
+	      md->type != EFI_RUNTIME_SERVICES_DATA) {
+		pr_err("ESRT header memory map type is invalid\n");
+		return;
+	}
+
 	max = efi_mem_desc_end(&md);
 	if (max < efi.esrt) {
 		pr_err("EFI memory descriptor is invalid. (esrt: %p max: %p)\n",
--- linux-x86.orig/arch/x86/platform/efi/quirks.c
+++ linux-x86/arch/x86/platform/efi/quirks.c
@@ -201,6 +201,11 @@ void __init efi_arch_mem_reserve(phys_ad
 		return;
 	}
 
+	if (md->attribute & EFI_MEMORY_RUNTIME ||
+	      md->type != EFI_BOOT_SERVICES_DATA) {
+		return;
+	}
+
 	size += addr % EFI_PAGE_SIZE;
 	size = round_up(size, EFI_PAGE_SIZE);
 	addr = round_down(addr, EFI_PAGE_SIZE);

> 
> > 
> > > How about move the if chunk early like below because it seems no need
> > > to sanity check the addr + size any more if the md is still RUNTIME?
> > 
> > My original version did as you suggest, but I changed it because we
> > *really* want to know if someone tries to reserve a range that spans
> > regions. That would be totally unexpected and a warning about a
> > potential bug/issue.
> 
> Matt, I'm fine if you prefer to capture the range checking errors.
> Would you like me to post it or just you send it out?
> 
> Thanks
> Dave

Thanks
Dave

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2017-03-21  7:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170308201616.GC8598@vader>
2017-03-09  6:38 ` kexec regression since 4.9 caused by efi Dave Young
2017-03-09  9:54   ` Omar Sandoval
2017-03-09 11:53     ` Ard Biesheuvel
2017-03-10  1:39       ` Dave Young
2017-03-16 12:15       ` Matt Fleming
2017-03-10  1:42     ` Dave Young
2017-03-13  7:37     ` Dave Young
2017-03-16 12:41       ` Matt Fleming
2017-03-16 17:50         ` Omar Sandoval
2017-04-03 23:54           ` Omar Sandoval
2017-03-17  2:09         ` Dave Young
2017-03-17 13:25           ` Ard Biesheuvel
2017-03-17 13:32           ` Matt Fleming
2017-03-20  2:14             ` Dave Young
2017-03-21  7:48               ` Dave Young [this message]
2017-03-22 16:10                 ` Ard Biesheuvel
2017-03-23  2:43                   ` Dave Young
2017-04-04 13:37               ` Matt Fleming
2017-04-05  1:23                 ` Dave Young

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170321074826.GA4571@dhcp-128-65.nay.redhat.com \
    --to=dyoung@redhat.com \
    --cc=kernel-team@fb.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@kernel.org \
    --cc=osandov@osandov.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox