Patch "x86/efi: Don't try to reserve runtime regions" has been added to the 4.10-stable tree

This is a note to let you know that I've just added the patch titled

x86/efi: Don't try to reserve runtime regions

to the 4.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
x86-efi-don-t-try-to-reserve-runtime-regions.patch
and it can be found in the queue-4.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From: Omar Sandoval <[email protected]>
Date: Wed, 12 Apr 2017 16:27:19 +0100
Subject: x86/efi: Don't try to reserve runtime regions

From: Omar Sandoval <[email protected]>

commit 6f6266a561306e206e0e31a5038f029b6a7b1d89 upstream.

Reserving a runtime region results in splitting the EFI memory descriptors for the runtime region. This results in runtime region descriptors with bogus memory mappings, leading to interesting crashes like the following during a kexec:

  general protection fault: 0000 [#1] SMP
  Modules linked in:
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1 #53
  Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05   09/30/2016
  RIP: 0010:virt_efi_set_variable()
  ...
  Call Trace:
   efi_delete_dummy_variable()
   efi_enter_virtual_mode()
   start_kernel()
   ? set_init_arg()
   x86_64_start_reservations()
   x86_64_start_kernel()
   start_cpu()
  ...
  Kernel panic - not syncing: Fatal exception

Runtime regions will not be freed and do not need to be reserved, so skip the memmap modification in this case.

---
 arch/x86/platform/efi/quirks.c |    4 ++++
 1 file changed, 4 insertions(+)

@@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_ad
 		return;
 	}
 
+	/* No need to reserve regions that will never be freed. */
+	if (md.attribute & EFI_MEMORY_RUNTIME)
+		return;
+
 	size += addr % EFI_PAGE_SIZE;
 	size = round_up(size, EFI_PAGE_SIZE);
 	addr = round_down(addr, EFI_PAGE_SIZE);

Patches currently in stable-queue which might be from [email protected] are

queue-4.10/x86-efi-don-t-try-to-reserve-runtime-regions.patch