[GIT PULL 0/2] EFI urgent fixes

[GIT PULL 0/2] EFI urgent fixes

[Matt Fleming]

Folks, please pull the following two fixes that address the boot hang
issue Waiman reported here,

  https://lkml.kernel.org/r/57DF56D4.50304@hpe.com

The following changes since commit 3be7988674ab33565700a37b210f502563d932e6:

  Linux 4.8-rc7 (2016-09-18 17:27:41 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-urgent

for you to fetch changes up to 1297667083d5442aafe3e337b9413bf02b114edb:

  x86/efi: Only map RAM into EFI page tables if in mixed-mode (2016-09-20 14:53:04 +0100)

----------------------------------------------------------------
 * Fix a boot hang on large memory machines (multiple terabyte) caused
   by type conversion errors in the x86 pat code - Matt Fleming

----------------------------------------------------------------
Matt Fleming (2):
      x86/mm/pat: Prevent hang during boot when mapping pages
      x86/efi: Only map RAM into EFI page tables if in mixed-mode

 arch/x86/mm/pageattr.c         | 21 +++++++++++----------
 arch/x86/platform/efi/efi_64.c |  2 +-
 2 files changed, 12 insertions(+), 11 deletions(-)

[PATCH 1/2] x86/mm/pat: Prevent hang during boot when mapping pages

[Matt Fleming]

There's a mixture of signed 32-bit and unsigned 32-bit and 64-bit data
types used for keeping track of how many pages have been mapped.

This leads to hangs during boot when mapping large numbers of pages
(multiple terabytes, as reported by Waiman) because those values are
interpreted as being negative.

commit 742563777e8d ("x86/mm/pat: Avoid truncation when converting
cpa->numpages to address") fixed one of those bugs, but there is
another lurking in __change_page_attr_set_clr().

Additionally, the return value type for the populate_*() functions can
return negative values when a large number of pages have been mapped,
triggering the error paths even though no error occurred.

Consistently use 64-bit types on 64-bit platforms when counting pages.
Even in the signed case this gives us room for regions 8PiB
(pebibytes) in size whilst still allowing the usual negative value
error checking idiom.

Reported-by: Waiman Long <waiman.long@hpe.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
CC: Theodore Ts'o <tytso@mit.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Scott J Norton <scott.norton@hpe.com>
Cc: Douglas Hatch <doug.hatch@hpe.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
---
 arch/x86/mm/pageattr.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 849dc09fa4f0..e3353c97d086 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -917,11 +917,11 @@ static void populate_pte(struct cpa_data *cpa,
 	}
 }
 
-static int populate_pmd(struct cpa_data *cpa,
-			unsigned long start, unsigned long end,
-			unsigned num_pages, pud_t *pud, pgprot_t pgprot)
+static long populate_pmd(struct cpa_data *cpa,
+			 unsigned long start, unsigned long end,
+			 unsigned num_pages, pud_t *pud, pgprot_t pgprot)
 {
-	unsigned int cur_pages = 0;
+	long cur_pages = 0;
 	pmd_t *pmd;
 	pgprot_t pmd_pgprot;
 
@@ -991,12 +991,12 @@ static int populate_pmd(struct cpa_data *cpa,
 	return num_pages;
 }
 
-static int populate_pud(struct cpa_data *cpa, unsigned long start, pgd_t *pgd,
-			pgprot_t pgprot)
+static long populate_pud(struct cpa_data *cpa, unsigned long start, pgd_t *pgd,
+			 pgprot_t pgprot)
 {
 	pud_t *pud;
 	unsigned long end;
-	int cur_pages = 0;
+	long cur_pages = 0;
 	pgprot_t pud_pgprot;
 
 	end = start + (cpa->numpages << PAGE_SHIFT);
@@ -1052,7 +1052,7 @@ static int populate_pud(struct cpa_data *cpa, unsigned long start, pgd_t *pgd,
 
 	/* Map trailing leftover */
 	if (start < end) {
-		int tmp;
+		long tmp;
 
 		pud = pud_offset(pgd, start);
 		if (pud_none(*pud))
@@ -1078,7 +1078,7 @@ static int populate_pgd(struct cpa_data *cpa, unsigned long addr)
 	pgprot_t pgprot = __pgprot(_KERNPG_TABLE);
 	pud_t *pud = NULL;	/* shut up gcc */
 	pgd_t *pgd_entry;
-	int ret;
+	long ret;
 
 	pgd_entry = cpa->pgd + pgd_index(addr);
 
@@ -1327,7 +1327,8 @@ static int cpa_process_alias(struct cpa_data *cpa)
 
 static int __change_page_attr_set_clr(struct cpa_data *cpa, int checkalias)
 {
-	int ret, numpages = cpa->numpages;
+	unsigned long numpages = cpa->numpages;
+	int ret;
 
 	while (numpages) {
 		/*
-- 
2.9.3

[PATCH 2/2] x86/efi: Only map RAM into EFI page tables if in mixed-mode

[Matt Fleming]

Waiman reported that booting with CONFIG_EFI_MIXED enabled on his
multi-terabyte HP machine results in boot crashes, because the EFI
region mapping functions loop forever while trying to map those
regions describing RAM.

While this patch doesn't fix the underlying hang, there's really no
reason to map EFI_CONVENTIONAL_MEMORY regions into the EFI page tables
when mixed-mode is not in use at runtime.

Reported-by: Waiman Long <waiman.long@hpe.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
CC: Theodore Ts'o <tytso@mit.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Scott J Norton <scott.norton@hpe.com>
Cc: Douglas Hatch <doug.hatch@hpe.com>
Cc: <stable@vger.kernel.org> # v4.6+
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
---
 arch/x86/platform/efi/efi_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 677e29e29473..8dd3784eb075 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -245,7 +245,7 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
 	 * text and allocate a new stack because we can't rely on the
 	 * stack pointer being < 4GB.
 	 */
-	if (!IS_ENABLED(CONFIG_EFI_MIXED))
+	if (!IS_ENABLED(CONFIG_EFI_MIXED) || efi_is_native())
 		return 0;
 
 	/*
-- 
2.9.3

Re: [GIT PULL 0/2] EFI urgent fixes

[Ingo Molnar]

* Matt Fleming <matt@codeblueprint.co.uk> wrote:

> Folks, please pull the following two fixes that address the boot hang
> issue Waiman reported here,
> 
>   https://lkml.kernel.org/r/57DF56D4.50304@hpe.com
> 
> The following changes since commit 3be7988674ab33565700a37b210f502563d932e6:
> 
>   Linux 4.8-rc7 (2016-09-18 17:27:41 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-urgent
> 
> for you to fetch changes up to 1297667083d5442aafe3e337b9413bf02b114edb:
> 
>   x86/efi: Only map RAM into EFI page tables if in mixed-mode (2016-09-20 14:53:04 +0100)
> 
> ----------------------------------------------------------------
>  * Fix a boot hang on large memory machines (multiple terabyte) caused
>    by type conversion errors in the x86 pat code - Matt Fleming
> 
> ----------------------------------------------------------------
> Matt Fleming (2):
>       x86/mm/pat: Prevent hang during boot when mapping pages
>       x86/efi: Only map RAM into EFI page tables if in mixed-mode
> 
>  arch/x86/mm/pageattr.c         | 21 +++++++++++----------
>  arch/x86/platform/efi/efi_64.c |  2 +-
>  2 files changed, 12 insertions(+), 11 deletions(-)

Pulled, thanks a lot Matt!

	Ingo

Re: [GIT PULL 0/2] EFI urgent fixes

[Waiman Long]

On 09/20/2016 10:48 AM, Matt Fleming wrote:
> Folks, please pull the following two fixes that address the boot hang
> issue Waiman reported here,
>
>    https://lkml.kernel.org/r/57DF56D4.50304@hpe.com
>
> The following changes since commit 3be7988674ab33565700a37b210f502563d932e6:
>
>    Linux 4.8-rc7 (2016-09-18 17:27:41 -0700)
>
> are available in the git repository at:
>
>    git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-urgent
>
> for you to fetch changes up to 1297667083d5442aafe3e337b9413bf02b114edb:
>
>    x86/efi: Only map RAM into EFI page tables if in mixed-mode (2016-09-20 14:53:04 +0100)
>
> ----------------------------------------------------------------
>   * Fix a boot hang on large memory machines (multiple terabyte) caused
>     by type conversion errors in the x86 pat code - Matt Fleming
>
> ----------------------------------------------------------------
> Matt Fleming (2):
>        x86/mm/pat: Prevent hang during boot when mapping pages
>        x86/efi: Only map RAM into EFI page tables if in mixed-mode
>
>   arch/x86/mm/pageattr.c         | 21 +++++++++++----------
>   arch/x86/platform/efi/efi_64.c |  2 +-
>   2 files changed, 12 insertions(+), 11 deletions(-)

Are you also going to send these fixes to the 4.6 and 4.7 stable trees 
as well?

Cheers,
Longman

Re: [GIT PULL 0/2] EFI urgent fixes

[Matt Fleming]

On Tue, 20 Sep, at 11:20:17AM, Waiman Long wrote:
> On 09/20/2016 10:48 AM, Matt Fleming wrote:
> >Folks, please pull the following two fixes that address the boot hang
> >issue Waiman reported here,
> >
> >   https://lkml.kernel.org/r/57DF56D4.50304@hpe.com
> >
> >The following changes since commit 3be7988674ab33565700a37b210f502563d932e6:
> >
> >   Linux 4.8-rc7 (2016-09-18 17:27:41 -0700)
> >
> >are available in the git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-urgent
> >
> >for you to fetch changes up to 1297667083d5442aafe3e337b9413bf02b114edb:
> >
> >   x86/efi: Only map RAM into EFI page tables if in mixed-mode (2016-09-20 14:53:04 +0100)
> >
> >----------------------------------------------------------------
> >  * Fix a boot hang on large memory machines (multiple terabyte) caused
> >    by type conversion errors in the x86 pat code - Matt Fleming
> >
> >----------------------------------------------------------------
> >Matt Fleming (2):
> >       x86/mm/pat: Prevent hang during boot when mapping pages
> >       x86/efi: Only map RAM into EFI page tables if in mixed-mode
> >
> >  arch/x86/mm/pageattr.c         | 21 +++++++++++----------
> >  arch/x86/platform/efi/efi_64.c |  2 +-
> >  2 files changed, 12 insertions(+), 11 deletions(-)
> 
> Are you also going to send these fixes to the 4.6 and 4.7 stable trees as
> well?

I just checked and I failed to tag the first patch for stable, though
I did mean to. Yes, I'll send them to stable once they're merged.