[GIT PULL] EFI urgent fix

[GIT PULL] EFI urgent fix

[Matt Fleming]

From: Matt Fleming <matt.fleming@intel.com>

Please pull the following fix from Zoltán which addresses a bug that
resulted in the the secondary GOP display being garbled when booting
using the EFI boot stub.

The following changes since commit 825fcfce81921c9cc4ef801d844793815721e458:

  MAINTAINERS: Change Matt Fleming's email address (2015-10-11 09:54:29 +0200)

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 dc1ea95fd23c36dd6be284334a0c8327d11d8c52:

  x86/efi: Fix multiple GOP device support (2015-10-11 11:40:54 +0100)

----------------------------------------------------------------
 * Fix booting using the EFI boot stub on platforms with multiple
   Graphics Output Protocol devices because currently the secondary
   display will be garbled on such systems - Zoltán Kővágó

----------------------------------------------------------------
Kővágó, Zoltán (1):
      x86/efi: Fix multiple GOP device support

 arch/x86/boot/compressed/eboot.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

[PATCH] x86/efi: Fix multiple GOP device support

[Matt Fleming]

From: Kővágó, Zoltán <dirty.ice.hu@gmail.com>

When multiple GOP devices exists, but none of them implements ConOut,
the code should just choose the first GOP (according to the comments).
But currently fb_base will refer to the last GOP, while other parameters
to the first GOP, which will likely result in a garbled display.

I can reliably reproduce this bug using my ASRock Z87M Extreme4
motherboard with CSM and integrated GPU disabled, and two PCIe video
cards (NVidia GT640 and GTX980), booting from efi-stub (booting from
grub works fine).  On the primary display the asrock logo remains and on
the secondary screen is garbled up completely.

Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
---
 arch/x86/boot/compressed/eboot.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index ee1b6d346b98..db51c1f27446 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -667,6 +667,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
 		bool conout_found = false;
 		void *dummy = NULL;
 		u32 h = handles[i];
+		u32 current_fb_base;
 
 		status = efi_call_early(handle_protocol, h,
 					proto, (void **)&gop32);
@@ -678,7 +679,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
 		if (status == EFI_SUCCESS)
 			conout_found = true;
 
-		status = __gop_query32(gop32, &info, &size, &fb_base);
+		status = __gop_query32(gop32, &info, &size, &current_fb_base);
 		if (status == EFI_SUCCESS && (!first_gop || conout_found)) {
 			/*
 			 * Systems that use the UEFI Console Splitter may
@@ -692,6 +693,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
 			pixel_format = info->pixel_format;
 			pixel_info = info->pixel_information;
 			pixels_per_scan_line = info->pixels_per_scan_line;
+			fb_base = current_fb_base;
 
 			/*
 			 * Once we've found a GOP supporting ConOut,
@@ -770,6 +772,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
 		bool conout_found = false;
 		void *dummy = NULL;
 		u64 h = handles[i];
+		u32 current_fb_base;
 
 		status = efi_call_early(handle_protocol, h,
 					proto, (void **)&gop64);
@@ -781,7 +784,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
 		if (status == EFI_SUCCESS)
 			conout_found = true;
 
-		status = __gop_query64(gop64, &info, &size, &fb_base);
+		status = __gop_query64(gop64, &info, &size, &current_fb_base);
 		if (status == EFI_SUCCESS && (!first_gop || conout_found)) {
 			/*
 			 * Systems that use the UEFI Console Splitter may
@@ -795,6 +798,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
 			pixel_format = info->pixel_format;
 			pixel_info = info->pixel_information;
 			pixels_per_scan_line = info->pixels_per_scan_line;
+			fb_base = current_fb_base;
 
 			/*
 			 * Once we've found a GOP supporting ConOut,
-- 
2.1.0

Re: [PATCH] x86/efi: Fix multiple GOP device support

[Ingo Molnar]

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

> From: Kővágó, Zoltán <dirty.ice.hu@gmail.com>
> 
> When multiple GOP devices exists, but none of them implements ConOut,
> the code should just choose the first GOP (according to the comments).
> But currently fb_base will refer to the last GOP, while other parameters
> to the first GOP, which will likely result in a garbled display.
> 
> I can reliably reproduce this bug using my ASRock Z87M Extreme4
> motherboard with CSM and integrated GPU disabled, and two PCIe video
> cards (NVidia GT640 and GTX980), booting from efi-stub (booting from
> grub works fine).  On the primary display the asrock logo remains and on
> the secondary screen is garbled up completely.
> 
> Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
> Cc: Matthew Garrett <mjg59@srcf.ucam.org>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
> ---
>  arch/x86/boot/compressed/eboot.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
> index ee1b6d346b98..db51c1f27446 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -667,6 +667,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
>  		bool conout_found = false;
>  		void *dummy = NULL;
>  		u32 h = handles[i];
> +		u32 current_fb_base;

Sigh, fb_base is u64...

> @@ -770,6 +772,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
>  		bool conout_found = false;
>  		void *dummy = NULL;
>  		u64 h = handles[i];
> +		u32 current_fb_base;

Ditto.

So I've applied it with that obvious bug fixed, but could you guys please double 
check how on earth this patch could possibly have worked fine in testing, without 
crashing 64-bit kernels?

Thanks,

	Ingo

Re: [PATCH] x86/efi: Fix multiple GOP device support

[Ingo Molnar]

* Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:

> From: Kővágó, Zoltán <dirty.ice.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 
> When multiple GOP devices exists, but none of them implements ConOut,
> the code should just choose the first GOP (according to the comments).
> But currently fb_base will refer to the last GOP, while other parameters
> to the first GOP, which will likely result in a garbled display.
> 
> I can reliably reproduce this bug using my ASRock Z87M Extreme4
> motherboard with CSM and integrated GPU disabled, and two PCIe video
> cards (NVidia GT640 and GTX980), booting from efi-stub (booting from
> grub works fine).  On the primary display the asrock logo remains and on
> the secondary screen is garbled up completely.
> 
> Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
> Cc: Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Signed-off-by: Matt Fleming <matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
>  arch/x86/boot/compressed/eboot.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
> index ee1b6d346b98..db51c1f27446 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -667,6 +667,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
>  		bool conout_found = false;
>  		void *dummy = NULL;
>  		u32 h = handles[i];
> +		u32 current_fb_base;

Sigh, fb_base is u64...

> @@ -770,6 +772,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
>  		bool conout_found = false;
>  		void *dummy = NULL;
>  		u64 h = handles[i];
> +		u32 current_fb_base;

Ditto.

So I've applied it with that obvious bug fixed, but could you guys please double 
check how on earth this patch could possibly have worked fine in testing, without 
crashing 64-bit kernels?

Thanks,

	Ingo

Re: [PATCH] x86/efi: Fix multiple GOP device support

[Ingo Molnar]

* Ingo Molnar <mingo@kernel.org> wrote:

> * Matt Fleming <matt@codeblueprint.co.uk> wrote:
> 
> > From: Kővágó, Zoltán <dirty.ice.hu@gmail.com>
> > 
> > When multiple GOP devices exists, but none of them implements ConOut,
> > the code should just choose the first GOP (according to the comments).
> > But currently fb_base will refer to the last GOP, while other parameters
> > to the first GOP, which will likely result in a garbled display.
> > 
> > I can reliably reproduce this bug using my ASRock Z87M Extreme4
> > motherboard with CSM and integrated GPU disabled, and two PCIe video
> > cards (NVidia GT640 and GTX980), booting from efi-stub (booting from
> > grub works fine).  On the primary display the asrock logo remains and on
> > the secondary screen is garbled up completely.
> > 
> > Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
> > Cc: Matthew Garrett <mjg59@srcf.ucam.org>
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Matt Fleming <matt.fleming@intel.com>
> > ---
> >  arch/x86/boot/compressed/eboot.c | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
> > index ee1b6d346b98..db51c1f27446 100644
> > --- a/arch/x86/boot/compressed/eboot.c
> > +++ b/arch/x86/boot/compressed/eboot.c
> > @@ -667,6 +667,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
> >  		bool conout_found = false;
> >  		void *dummy = NULL;
> >  		u32 h = handles[i];
> > +		u32 current_fb_base;
> 
> Sigh, fb_base is u64...
> 
> > @@ -770,6 +772,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
> >  		bool conout_found = false;
> >  		void *dummy = NULL;
> >  		u64 h = handles[i];
> > +		u32 current_fb_base;
> 
> Ditto.
> 
> So I've applied it with that obvious bug fixed, but could you guys please double 
> check how on earth this patch could possibly have worked fine in testing, without 
> crashing 64-bit kernels?

Ah, I see, this is a subtle semantic conflict with pending v4.4 EFI changes in 
tip:core/efi, which changed fb_base from u32 to u64:

  ae2ee627dc87 ("efifb: Add support for 64-bit frame buffer addresses")

(Interestingly there was no textual conflict between this patch and that commit.)

So the fix patch is fine as-is for v4.3, but needs a conflict resolution for the 
pending v4.4 commit.

I've applied it that way.

Thanks,

	Ingo

Re: [PATCH] x86/efi: Fix multiple GOP device support

[Ingo Molnar]

* Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:

> * Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:
> 
> > From: Kővágó, Zoltán <dirty.ice.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > 
> > When multiple GOP devices exists, but none of them implements ConOut,
> > the code should just choose the first GOP (according to the comments).
> > But currently fb_base will refer to the last GOP, while other parameters
> > to the first GOP, which will likely result in a garbled display.
> > 
> > I can reliably reproduce this bug using my ASRock Z87M Extreme4
> > motherboard with CSM and integrated GPU disabled, and two PCIe video
> > cards (NVidia GT640 and GTX980), booting from efi-stub (booting from
> > grub works fine).  On the primary display the asrock logo remains and on
> > the secondary screen is garbled up completely.
> > 
> > Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
> > Cc: Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
> > Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> > Signed-off-by: Matt Fleming <matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > ---
> >  arch/x86/boot/compressed/eboot.c | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
> > index ee1b6d346b98..db51c1f27446 100644
> > --- a/arch/x86/boot/compressed/eboot.c
> > +++ b/arch/x86/boot/compressed/eboot.c
> > @@ -667,6 +667,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
> >  		bool conout_found = false;
> >  		void *dummy = NULL;
> >  		u32 h = handles[i];
> > +		u32 current_fb_base;
> 
> Sigh, fb_base is u64...
> 
> > @@ -770,6 +772,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
> >  		bool conout_found = false;
> >  		void *dummy = NULL;
> >  		u64 h = handles[i];
> > +		u32 current_fb_base;
> 
> Ditto.
> 
> So I've applied it with that obvious bug fixed, but could you guys please double 
> check how on earth this patch could possibly have worked fine in testing, without 
> crashing 64-bit kernels?

Ah, I see, this is a subtle semantic conflict with pending v4.4 EFI changes in 
tip:core/efi, which changed fb_base from u32 to u64:

  ae2ee627dc87 ("efifb: Add support for 64-bit frame buffer addresses")

(Interestingly there was no textual conflict between this patch and that commit.)

So the fix patch is fine as-is for v4.3, but needs a conflict resolution for the 
pending v4.4 commit.

I've applied it that way.

Thanks,

	Ingo

Re: [PATCH] x86/efi: Fix multiple GOP device support

[Matt Fleming]

On Wed, 14 Oct, at 04:51:04PM, Ingo Molnar wrote:
> 
> Ah, I see, this is a subtle semantic conflict with pending v4.4 EFI changes in 
> tip:core/efi, which changed fb_base from u32 to u64:
> 
>   ae2ee627dc87 ("efifb: Add support for 64-bit frame buffer addresses")
 
Yeah, that's exactly the issue. I should have given you a heads up
about this but I forgot that there were two patches to this area in
separate branches. 

> (Interestingly there was no textual conflict between this patch and that commit.)
> 
> So the fix patch is fine as-is for v4.3, but needs a conflict resolution for the 
> pending v4.4 commit.
> 
> I've applied it that way.

Do you need me to send a patch on top or have you taken care of the
semantic conflict for v4.4? (the change you originally proposed,
s/u32/u64/, looked fine)

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [PATCH] x86/efi: Fix multiple GOP device support

[Ingo Molnar]

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

> > So the fix patch is fine as-is for v4.3, but needs a conflict resolution for 
> > the pending v4.4 commit.
> > 
> > I've applied it that way.
> 
> Do you need me to send a patch on top or have you taken care of the
> semantic conflict for v4.4? (the change you originally proposed,
> s/u32/u64/, looked fine)

So to not break bisection in hard to debug ways, I made this fixup in the merge 
commit of your changes, and documented it all in the merge commit message:

commit 790a2ee2427852cff50993c98f15ed88511e9af0
Merge: c7d77a7980e4 0f96a99dab36
Author: Ingo Molnar <mingo@kernel.org>
Date:   Wed Oct 14 16:05:40 2015 +0200

    Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into core/efi
    
    Pull v4.4 EFI updates from Matt Fleming:
    
      - Make the EFI System Resource Table (ESRT) driver explicitly
        non-modular by ripping out the module_* code since Kconfig doesn't
        allow it to be built as a module anyway. (Paul Gortmaker)
    
      - Make the x86 efi=debug kernel parameter, which enables EFI debug
        code and output, generic and usable by arm64. (Leif Lindholm)
    
      - Add support to the x86 EFI boot stub for 64-bit Graphics Output
        Protocol frame buffer addresses. (Matt Fleming)
    
      - Detect when the UEFI v2.5 EFI_PROPERTIES_TABLE feature is enabled
        in the firmware and set an efi.flags bit so the kernel knows when
        it can apply more strict runtime mapping attributes - Ard Biesheuvel
    
      - Auto-load the efi-pstore module on EFI systems, just like we
        currently do for the efivars module. (Ben Hutchings)
    
      - Add "efi_fake_mem" kernel parameter which allows the system's EFI
        memory map to be updated with additional attributes for specific
        memory ranges. This is useful for testing the kernel code that handles
        the EFI_MEMORY_MORE_RELIABLE memmap bit even if your firmware
        doesn't include support. (Taku Izumi)
    
    Note: there is a semantic conflict between the following two commits:
    
      8a53554e12e9 ("x86/efi: Fix multiple GOP device support")
      ae2ee627dc87 ("efifb: Add support for 64-bit frame buffer addresses")
    
    I fixed up the interaction in the merge commit, changing the type of
    current_fb_base from u32 to u64.
    
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

Thanks,

	Ingo

Re: [PATCH] x86/efi: Fix multiple GOP device support

[Ingo Molnar]

* Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:

> > So the fix patch is fine as-is for v4.3, but needs a conflict resolution for 
> > the pending v4.4 commit.
> > 
> > I've applied it that way.
> 
> Do you need me to send a patch on top or have you taken care of the
> semantic conflict for v4.4? (the change you originally proposed,
> s/u32/u64/, looked fine)

So to not break bisection in hard to debug ways, I made this fixup in the merge 
commit of your changes, and documented it all in the merge commit message:

commit 790a2ee2427852cff50993c98f15ed88511e9af0
Merge: c7d77a7980e4 0f96a99dab36
Author: Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Date:   Wed Oct 14 16:05:40 2015 +0200

    Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into core/efi
    
    Pull v4.4 EFI updates from Matt Fleming:
    
      - Make the EFI System Resource Table (ESRT) driver explicitly
        non-modular by ripping out the module_* code since Kconfig doesn't
        allow it to be built as a module anyway. (Paul Gortmaker)
    
      - Make the x86 efi=debug kernel parameter, which enables EFI debug
        code and output, generic and usable by arm64. (Leif Lindholm)
    
      - Add support to the x86 EFI boot stub for 64-bit Graphics Output
        Protocol frame buffer addresses. (Matt Fleming)
    
      - Detect when the UEFI v2.5 EFI_PROPERTIES_TABLE feature is enabled
        in the firmware and set an efi.flags bit so the kernel knows when
        it can apply more strict runtime mapping attributes - Ard Biesheuvel
    
      - Auto-load the efi-pstore module on EFI systems, just like we
        currently do for the efivars module. (Ben Hutchings)
    
      - Add "efi_fake_mem" kernel parameter which allows the system's EFI
        memory map to be updated with additional attributes for specific
        memory ranges. This is useful for testing the kernel code that handles
        the EFI_MEMORY_MORE_RELIABLE memmap bit even if your firmware
        doesn't include support. (Taku Izumi)
    
    Note: there is a semantic conflict between the following two commits:
    
      8a53554e12e9 ("x86/efi: Fix multiple GOP device support")
      ae2ee627dc87 ("efifb: Add support for 64-bit frame buffer addresses")
    
    I fixed up the interaction in the merge commit, changing the type of
    current_fb_base from u32 to u64.
    
    Signed-off-by: Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Thanks,

	Ingo

Re: [PATCH] x86/efi: Fix multiple GOP device support

[Matt Fleming]

On Wed, 14 Oct, at 05:04:26PM, Ingo Molnar wrote:
> 
> * Matt Fleming <matt@codeblueprint.co.uk> wrote:
> 
> > > So the fix patch is fine as-is for v4.3, but needs a conflict resolution for 
> > > the pending v4.4 commit.
> > > 
> > > I've applied it that way.
> > 
> > Do you need me to send a patch on top or have you taken care of the
> > semantic conflict for v4.4? (the change you originally proposed,
> > s/u32/u64/, looked fine)
> 
> So to not break bisection in hard to debug ways, I made this fixup in the merge 
> commit of your changes, and documented it all in the merge commit message:
> 
> commit 790a2ee2427852cff50993c98f15ed88511e9af0
> Merge: c7d77a7980e4 0f96a99dab36
> Author: Ingo Molnar <mingo@kernel.org>
> Date:   Wed Oct 14 16:05:40 2015 +0200

[...]

>     Note: there is a semantic conflict between the following two commits:
>     
>       8a53554e12e9 ("x86/efi: Fix multiple GOP device support")
>       ae2ee627dc87 ("efifb: Add support for 64-bit frame buffer addresses")
>     
>     I fixed up the interaction in the merge commit, changing the type of
>     current_fb_base from u32 to u64.
>     
>     Signed-off-by: Ingo Molnar <mingo@kernel.org>

Awesome, thanks Ingo.

-- 
Matt Fleming, Intel Open Source Technology Center

[tip:core/efi] x86/efi: Fix multiple GOP device support

[tip-bot for Kővágó, Zoltán]

Commit-ID:  8a53554e12e98d1759205afd7b8e9e2ea0936f48
Gitweb:     http://git.kernel.org/tip/8a53554e12e98d1759205afd7b8e9e2ea0936f48
Author:     Kővágó, Zoltán <dirty.ice.hu@gmail.com>
AuthorDate: Mon, 12 Oct 2015 15:13:56 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 14 Oct 2015 16:02:43 +0200

x86/efi: Fix multiple GOP device support

When multiple GOP devices exists, but none of them implements
ConOut, the code should just choose the first GOP (according to
the comments). But currently 'fb_base' will refer to the last GOP,
while other parameters to the first GOP, which will likely
result in a garbled display.

I can reliably reproduce this bug using my ASRock Z87M Extreme4
motherboard with CSM and integrated GPU disabled, and two PCIe
video cards (NVidia GT640 and GTX980), booting from efi-stub
(booting from grub works fine).  On the primary display the
ASRock logo remains and on the secondary screen it is garbled
up completely.

Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Cc: <stable@vger.kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1444659236-24837-2-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/boot/compressed/eboot.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index ee1b6d3..db51c1f 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -667,6 +667,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
 		bool conout_found = false;
 		void *dummy = NULL;
 		u32 h = handles[i];
+		u32 current_fb_base;
 
 		status = efi_call_early(handle_protocol, h,
 					proto, (void **)&gop32);
@@ -678,7 +679,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
 		if (status == EFI_SUCCESS)
 			conout_found = true;
 
-		status = __gop_query32(gop32, &info, &size, &fb_base);
+		status = __gop_query32(gop32, &info, &size, &current_fb_base);
 		if (status == EFI_SUCCESS && (!first_gop || conout_found)) {
 			/*
 			 * Systems that use the UEFI Console Splitter may
@@ -692,6 +693,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
 			pixel_format = info->pixel_format;
 			pixel_info = info->pixel_information;
 			pixels_per_scan_line = info->pixels_per_scan_line;
+			fb_base = current_fb_base;
 
 			/*
 			 * Once we've found a GOP supporting ConOut,
@@ -770,6 +772,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
 		bool conout_found = false;
 		void *dummy = NULL;
 		u64 h = handles[i];
+		u32 current_fb_base;
 
 		status = efi_call_early(handle_protocol, h,
 					proto, (void **)&gop64);
@@ -781,7 +784,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
 		if (status == EFI_SUCCESS)
 			conout_found = true;
 
-		status = __gop_query64(gop64, &info, &size, &fb_base);
+		status = __gop_query64(gop64, &info, &size, &current_fb_base);
 		if (status == EFI_SUCCESS && (!first_gop || conout_found)) {
 			/*
 			 * Systems that use the UEFI Console Splitter may
@@ -795,6 +798,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
 			pixel_format = info->pixel_format;
 			pixel_info = info->pixel_information;
 			pixels_per_scan_line = info->pixels_per_scan_line;
+			fb_base = current_fb_base;
 
 			/*
 			 * Once we've found a GOP supporting ConOut,

[GIT PULL] EFI urgent fix

[Matt Fleming]

Folks, please pull the single below fix from Omar which fixes a kexec
boot regression.

I've based the pull on tip/efi/urgent since the EFI urgent queue
hasn't reached Linus' tree yet.

The following changes since commit 55d728a40d368ba80443be85c02e641fc9082a3f:

  efi/fb: Avoid reconfiguration of BAR that covers the framebuffer (2017-04-05 12:25:53 +0200)

are available in the git repository at:

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

for you to fetch changes up to 09ca0b10e8100a48aa94eb8649f4c6c904e5d196:

  x86/efi: Don't try to reserve runtime regions (2017-04-12 16:17:20 +0100)

----------------------------------------------------------------
 - Fix a crash on kexec boot introduced by the recent
   efi_mem_reserve() code in the ESRT driver, which double-reserved
   EFI runtime regions - Omar Sandoval

----------------------------------------------------------------
Omar Sandoval (1):
      x86/efi: Don't try to reserve runtime regions

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

[GIT PULL] EFI urgent fix

[Matt Fleming]

Folks, please pull the below fix from Jiri which fixes a triple fault
affecting the Lenovo Yogas since v4.8.

The following changes since commit 7a308bb3016f57e5be11a677d15b821536419d36:

  Linux 4.10-rc5 (2017-01-22 12:54:15 -0800)

are available in the git repository at:

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

for you to fetch changes up to 090abfc9dc7faf3f84799f956158c8c3af149a81:

  x86/efi: Always map first physical page into EFI pagetables (2017-01-27 20:20:01 +0000)

----------------------------------------------------------------
 * Fix triple fault on boot affecting Lenovo Yoga. The firmware on
   these machines will write to the zero page even though it's marked
   EFI_CONVENTIONAL_MEMORY, so we must ensure it's mapped in the EFI
   page tables - Jiri Kosina

----------------------------------------------------------------
Jiri Kosina (1):
      x86/efi: Always map first physical page into EFI pagetables

 arch/x86/platform/efi/efi_64.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

[GIT PULL] EFI urgent fix

[Matt Fleming]

Folks, please pull the below fix from Jiri which fixes a triple fault
affecting the Lenovo Yogas since v4.8.

The following changes since commit 7a308bb3016f57e5be11a677d15b821536419d36:

  Linux 4.10-rc5 (2017-01-22 12:54:15 -0800)

are available in the git repository at:

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

for you to fetch changes up to 090abfc9dc7faf3f84799f956158c8c3af149a81:

  x86/efi: Always map first physical page into EFI pagetables (2017-01-27 20:20:01 +0000)

----------------------------------------------------------------
 * Fix triple fault on boot affecting Lenovo Yoga. The firmware on
   these machines will write to the zero page even though it's marked
   EFI_CONVENTIONAL_MEMORY, so we must ensure it's mapped in the EFI
   page tables - Jiri Kosina

----------------------------------------------------------------
Jiri Kosina (1):
      x86/efi: Always map first physical page into EFI pagetables

 arch/x86/platform/efi/efi_64.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

[GIT PULL] EFI urgent fix

[Matt Fleming]

The following changes since commit c10fcb14c7afd6688c7b197a814358fecf244222:

  x86/sysfb_efi: Fix valid BAR address range check (2016-05-05 16:01:00 +0200)

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 6f4c184576aeb5594b8d21f9e7206b7b62e3d96e:

  x86/efi: Fix 7th argument to efi_call (2016-05-13 21:12:13 +0100)

----------------------------------------------------------------
 * Fix passing of 7 parameters or more to efi_call. This issue is only
   triggered on SGI/UV systems - Alex Thorlton

----------------------------------------------------------------
Alex Thorlton (1):
      x86/efi: Fix 7th argument to efi_call

 arch/x86/platform/efi/efi_stub_64.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[GIT PULL] EFI urgent fix

[Matt Fleming]

The following changes since commit c10fcb14c7afd6688c7b197a814358fecf244222:

  x86/sysfb_efi: Fix valid BAR address range check (2016-05-05 16:01:00 +0200)

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 6f4c184576aeb5594b8d21f9e7206b7b62e3d96e:

  x86/efi: Fix 7th argument to efi_call (2016-05-13 21:12:13 +0100)

----------------------------------------------------------------
 * Fix passing of 7 parameters or more to efi_call. This issue is only
   triggered on SGI/UV systems - Alex Thorlton

----------------------------------------------------------------
Alex Thorlton (1):
      x86/efi: Fix 7th argument to efi_call

 arch/x86/platform/efi/efi_stub_64.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [GIT PULL] EFI urgent fix

[Ingo Molnar]

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

> Folks, please pull the following fix from Laszlo that ensures we don't
> perform an out-of-bounds access when matching EFI variable names
> against the variable protection whitelist.
> 
> The following changes since commit c3b46c73264b03000d1e18b22f5caf63332547c9:
> 
>   Linux 4.6-rc4 (2016-04-17 19:13:32 -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 630ba0cc7a6dbafbdee43795617c872b35cde1b4:
> 
>   efi: Fix out-of-bounds read in variable_matches() (2016-04-22 19:41:41 +0100)
> 
> ----------------------------------------------------------------
>  * Avoid out-of-bounds access in the efivars code when performing
>    string matching on converted EFI variable names - Laszlo Ersek
> 
> ----------------------------------------------------------------
> Laszlo Ersek (1):
>       efi: Fix out-of-bounds read in variable_matches()
> 
>  drivers/firmware/efi/vars.c | 37 ++++++++++++++++++++++++++-----------
>  1 file changed, 26 insertions(+), 11 deletions(-)

Pulled into tip:efi/urgent, thanks Matt!

	Ingo

[GIT PULL] EFI urgent fix

[Matt Fleming]

Folks, please pull the following fix from Laszlo that ensures we don't
perform an out-of-bounds access when matching EFI variable names
against the variable protection whitelist.

The following changes since commit c3b46c73264b03000d1e18b22f5caf63332547c9:

  Linux 4.6-rc4 (2016-04-17 19:13:32 -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 630ba0cc7a6dbafbdee43795617c872b35cde1b4:

  efi: Fix out-of-bounds read in variable_matches() (2016-04-22 19:41:41 +0100)

----------------------------------------------------------------
 * Avoid out-of-bounds access in the efivars code when performing
   string matching on converted EFI variable names - Laszlo Ersek

----------------------------------------------------------------
Laszlo Ersek (1):
      efi: Fix out-of-bounds read in variable_matches()

 drivers/firmware/efi/vars.c | 37 ++++++++++++++++++++++++++-----------
 1 file changed, 26 insertions(+), 11 deletions(-)

[GIT PULL] EFI urgent fix

[Matt Fleming]

Folks, please pull the following fix from Laszlo that ensures we don't
perform an out-of-bounds access when matching EFI variable names
against the variable protection whitelist.

The following changes since commit c3b46c73264b03000d1e18b22f5caf63332547c9:

  Linux 4.6-rc4 (2016-04-17 19:13:32 -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 630ba0cc7a6dbafbdee43795617c872b35cde1b4:

  efi: Fix out-of-bounds read in variable_matches() (2016-04-22 19:41:41 +0100)

----------------------------------------------------------------
 * Avoid out-of-bounds access in the efivars code when performing
   string matching on converted EFI variable names - Laszlo Ersek

----------------------------------------------------------------
Laszlo Ersek (1):
      efi: Fix out-of-bounds read in variable_matches()

 drivers/firmware/efi/vars.c | 37 ++++++++++++++++++++++++++-----------
 1 file changed, 26 insertions(+), 11 deletions(-)

Re: [GIT PULL] EFI urgent fix

[Ingo Molnar]

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

> Folks,
> 
> Please pull the following fix for an arm64 boot crash reported by Mark
> Salter with 64KB granule kernels. It is also tagged for stable.
> 
> The following changes since commit 591b1d8d86074ac3a3163d89bcfe7b232cf83902:
> 
>   x86/mm/pkeys: Add missing Documentation (2016-03-29 11:21:17 +0200)
> 
> 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 7cc8cbcf82d165dd658d89a7a287140948e76413:
> 
>   efi/arm64: Don't apply MEMBLOCK_NOMAP to UEFI memory map mapping (2016-03-31 21:33:50 +0100)
> 
> ----------------------------------------------------------------
>  * Fix a boot crash on arm64 caused by a recent commit to mark the EFI
>    memory map as 'MEMBLOCK_NOMAP' which causes the regions to be
>    omitted from the kernel direct mapping - Ard Biesheuvel
> 
> ----------------------------------------------------------------
> Ard Biesheuvel (1):
>       efi/arm64: Don't apply MEMBLOCK_NOMAP to UEFI memory map mapping
> 
>  drivers/firmware/efi/arm-init.c | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)

Pulled, thanks Matt!

	Ingo

Re: [GIT PULL] EFI urgent fix

[Ingo Molnar]

* Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:

> Folks,
> 
> Please pull the following fix for an arm64 boot crash reported by Mark
> Salter with 64KB granule kernels. It is also tagged for stable.
> 
> The following changes since commit 591b1d8d86074ac3a3163d89bcfe7b232cf83902:
> 
>   x86/mm/pkeys: Add missing Documentation (2016-03-29 11:21:17 +0200)
> 
> 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 7cc8cbcf82d165dd658d89a7a287140948e76413:
> 
>   efi/arm64: Don't apply MEMBLOCK_NOMAP to UEFI memory map mapping (2016-03-31 21:33:50 +0100)
> 
> ----------------------------------------------------------------
>  * Fix a boot crash on arm64 caused by a recent commit to mark the EFI
>    memory map as 'MEMBLOCK_NOMAP' which causes the regions to be
>    omitted from the kernel direct mapping - Ard Biesheuvel
> 
> ----------------------------------------------------------------
> Ard Biesheuvel (1):
>       efi/arm64: Don't apply MEMBLOCK_NOMAP to UEFI memory map mapping
> 
>  drivers/firmware/efi/arm-init.c | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)

Pulled, thanks Matt!

	Ingo

[GIT PULL] EFI urgent fix

[Matt Fleming]

Folks,

Please pull the following fix for an arm64 boot crash reported by Mark
Salter with 64KB granule kernels. It is also tagged for stable.

The following changes since commit 591b1d8d86074ac3a3163d89bcfe7b232cf83902:

  x86/mm/pkeys: Add missing Documentation (2016-03-29 11:21:17 +0200)

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 7cc8cbcf82d165dd658d89a7a287140948e76413:

  efi/arm64: Don't apply MEMBLOCK_NOMAP to UEFI memory map mapping (2016-03-31 21:33:50 +0100)

----------------------------------------------------------------
 * Fix a boot crash on arm64 caused by a recent commit to mark the EFI
   memory map as 'MEMBLOCK_NOMAP' which causes the regions to be
   omitted from the kernel direct mapping - Ard Biesheuvel

----------------------------------------------------------------
Ard Biesheuvel (1):
      efi/arm64: Don't apply MEMBLOCK_NOMAP to UEFI memory map mapping

 drivers/firmware/efi/arm-init.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

Re: [GIT PULL] EFI urgent fix

[Thomas Gleixner]

On Wed, 4 Nov 2015, Matt Fleming wrote:
> for you to fetch changes up to 5965d1bbeba70fe3626e4537f4729283cb0e75f7:
> 
>   x86/setup: Fix recent boot crash on 32-bit SMP machines (2015-11-04 09:26:24 +0000)

I just picked that up manually :)

Re: [GIT PULL] EFI urgent fix

[Thomas Gleixner]

On Wed, 4 Nov 2015, Matt Fleming wrote:
> for you to fetch changes up to 5965d1bbeba70fe3626e4537f4729283cb0e75f7:
> 
>   x86/setup: Fix recent boot crash on 32-bit SMP machines (2015-11-04 09:26:24 +0000)

I just picked that up manually :)

[GIT PULL] EFI urgent fix

[Matt Fleming]

Folks, the LKP robot reported an issue with Paolo's recent bug fix
that syncs the identity mapping in 'initial_page_table'. Turns out
that KERNEL_PGD_PTRS is not the correct constant to use when copying
to the lower region because that's every PGD from PAGE_OFFSET to the
end of the addressable memory.

Crucially, KERNEL_PGD_PTRS > KERNEL_PGD_BOUNDARY and so the patch ends
up trashing some of the kernel mappings in 'initial_page'table,
leading to boot crashes on 32-bit SMP when bringing APs online.

The following changes since commit 9ee870feaa9e0c6abef95a3b1fc518d88adfa2d3:

  Merge branch 'x86/cpufeature' into x86/urgent, to pick up pending Intel MID change (2015-11-03 12:00:40 +0100)

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 5965d1bbeba70fe3626e4537f4729283cb0e75f7:

  x86/setup: Fix recent boot crash on 32-bit SMP machines (2015-11-04 09:26:24 +0000)

----------------------------------------------------------------
 * Avoid trashing the kernel mappings in 'initial_page_table' when
   copying the identity mapping from 'swapper_pg_dir'. This bug was
   introduced by a bug fix in v4.3 which erroneously copies too many
   entries from 'swapper_pg_dir'.

----------------------------------------------------------------
Matt Fleming (1):
      x86/setup: Fix recent boot crash on 32-bit SMP machines

 arch/x86/kernel/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[GIT PULL] EFI urgent fix

[Matt Fleming]

Folks, the LKP robot reported an issue with Paolo's recent bug fix
that syncs the identity mapping in 'initial_page_table'. Turns out
that KERNEL_PGD_PTRS is not the correct constant to use when copying
to the lower region because that's every PGD from PAGE_OFFSET to the
end of the addressable memory.

Crucially, KERNEL_PGD_PTRS > KERNEL_PGD_BOUNDARY and so the patch ends
up trashing some of the kernel mappings in 'initial_page'table,
leading to boot crashes on 32-bit SMP when bringing APs online.

The following changes since commit 9ee870feaa9e0c6abef95a3b1fc518d88adfa2d3:

  Merge branch 'x86/cpufeature' into x86/urgent, to pick up pending Intel MID change (2015-11-03 12:00:40 +0100)

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 5965d1bbeba70fe3626e4537f4729283cb0e75f7:

  x86/setup: Fix recent boot crash on 32-bit SMP machines (2015-11-04 09:26:24 +0000)

----------------------------------------------------------------
 * Avoid trashing the kernel mappings in 'initial_page_table' when
   copying the identity mapping from 'swapper_pg_dir'. This bug was
   introduced by a bug fix in v4.3 which erroneously copies too many
   entries from 'swapper_pg_dir'.

----------------------------------------------------------------
Matt Fleming (1):
      x86/setup: Fix recent boot crash on 32-bit SMP machines

 arch/x86/kernel/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [GIT PULL] EFI urgent fix

[Ingo Molnar]

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

> From: Matt Fleming <matt.fleming@intel.com>
> 
> Folks, the below fix from Paolo addresses an issue causing 32-bit
> non-PAE kernels to triple fault on EFI boot. The issue is that the
> physical address of the GDT that gets used in efi_call_phys_prolog()
> won't be covered by the identitty mapping in initial_page_table.
> 
> The following changes since commit 8a53554e12e98d1759205afd7b8e9e2ea0936f48:
> 
>   x86/efi: Fix multiple GOP device support (2015-10-14 16:02:43 +0200)
> 
> 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 f5f3497cad8c8416a74b9aaceb127908755d020a:
> 
>   x86/setup: Extend low identity map to cover whole kernel range (2015-10-16 10:52:29 +0100)
> 
> ----------------------------------------------------------------
>  * Ensure that the identity mapping in initial_page_table is updated
>    to cover the entire kernel range. This fixes a triple fault on
>    non-PAE kernels when booting on 32-bit EFI due to accessing an
>    unmapped GDT in efi_call_phys_prolog() - Paolo Bonzini
> 
> ----------------------------------------------------------------
> Paolo Bonzini (1):
>       x86/setup: Extend low identity map to cover whole kernel range
> 
>  arch/x86/kernel/setup.c | 8 ++++++++
>  1 file changed, 8 insertions(+)

Pulled, thanks Matt!

	Ingo

Re: [GIT PULL] EFI urgent fix

[Ingo Molnar]

* Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:

> From: Matt Fleming <matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> 
> Folks, the below fix from Paolo addresses an issue causing 32-bit
> non-PAE kernels to triple fault on EFI boot. The issue is that the
> physical address of the GDT that gets used in efi_call_phys_prolog()
> won't be covered by the identitty mapping in initial_page_table.
> 
> The following changes since commit 8a53554e12e98d1759205afd7b8e9e2ea0936f48:
> 
>   x86/efi: Fix multiple GOP device support (2015-10-14 16:02:43 +0200)
> 
> 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 f5f3497cad8c8416a74b9aaceb127908755d020a:
> 
>   x86/setup: Extend low identity map to cover whole kernel range (2015-10-16 10:52:29 +0100)
> 
> ----------------------------------------------------------------
>  * Ensure that the identity mapping in initial_page_table is updated
>    to cover the entire kernel range. This fixes a triple fault on
>    non-PAE kernels when booting on 32-bit EFI due to accessing an
>    unmapped GDT in efi_call_phys_prolog() - Paolo Bonzini
> 
> ----------------------------------------------------------------
> Paolo Bonzini (1):
>       x86/setup: Extend low identity map to cover whole kernel range
> 
>  arch/x86/kernel/setup.c | 8 ++++++++
>  1 file changed, 8 insertions(+)

Pulled, thanks Matt!

	Ingo

[GIT PULL] EFI urgent fix

[Matt Fleming]

From: Matt Fleming <matt.fleming@intel.com>

Folks, the below fix from Paolo addresses an issue causing 32-bit
non-PAE kernels to triple fault on EFI boot. The issue is that the
physical address of the GDT that gets used in efi_call_phys_prolog()
won't be covered by the identitty mapping in initial_page_table.

The following changes since commit 8a53554e12e98d1759205afd7b8e9e2ea0936f48:

  x86/efi: Fix multiple GOP device support (2015-10-14 16:02:43 +0200)

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 f5f3497cad8c8416a74b9aaceb127908755d020a:

  x86/setup: Extend low identity map to cover whole kernel range (2015-10-16 10:52:29 +0100)

----------------------------------------------------------------
 * Ensure that the identity mapping in initial_page_table is updated
   to cover the entire kernel range. This fixes a triple fault on
   non-PAE kernels when booting on 32-bit EFI due to accessing an
   unmapped GDT in efi_call_phys_prolog() - Paolo Bonzini

----------------------------------------------------------------
Paolo Bonzini (1):
      x86/setup: Extend low identity map to cover whole kernel range

 arch/x86/kernel/setup.c | 8 ++++++++
 1 file changed, 8 insertions(+)

[GIT PULL] EFI urgent fix

[Matt Fleming]

From: Matt Fleming <matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

Folks, the below fix from Paolo addresses an issue causing 32-bit
non-PAE kernels to triple fault on EFI boot. The issue is that the
physical address of the GDT that gets used in efi_call_phys_prolog()
won't be covered by the identitty mapping in initial_page_table.

The following changes since commit 8a53554e12e98d1759205afd7b8e9e2ea0936f48:

  x86/efi: Fix multiple GOP device support (2015-10-14 16:02:43 +0200)

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 f5f3497cad8c8416a74b9aaceb127908755d020a:

  x86/setup: Extend low identity map to cover whole kernel range (2015-10-16 10:52:29 +0100)

----------------------------------------------------------------
 * Ensure that the identity mapping in initial_page_table is updated
   to cover the entire kernel range. This fixes a triple fault on
   non-PAE kernels when booting on 32-bit EFI due to accessing an
   unmapped GDT in efi_call_phys_prolog() - Paolo Bonzini

----------------------------------------------------------------
Paolo Bonzini (1):
      x86/setup: Extend low identity map to cover whole kernel range

 arch/x86/kernel/setup.c | 8 ++++++++
 1 file changed, 8 insertions(+)

Re: [GIT PULL] EFI urgent fix

[Ingo Molnar]

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

> Folks,
> 
> Please pull the following fix from Tony that addresses a bug in the EFI
> CPER driver preventing it from working with memory error records as
> described in the UEFI 2.2 spec.
> 
> The following changes since commit d67e199611b986b345ea3087ee2e4a15da1c98b3:
> 
>   efi: Fix error handling in add_sysfs_runtime_map_entry() (2015-05-05 16:20:13 +0100)
> 
> 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 4c62360d7562a20c996836d163259c87d9378120:
> 
>   efi: Handle memory error structures produced based on old versions of standard (2015-07-15 13:30:38 +0100)
> 
> ----------------------------------------------------------------
>  * Fix a bug in the Common Platform Error Record (CPER) driver that
>    caused old UEFI spec (< 2.3) versions of the memory error record
>    structure to be declared invalid - Tony Luck
> 
> ----------------------------------------------------------------
> Tony Luck (1):
>       efi: Handle memory error structures produced based on old versions of standard
> 
>  drivers/firmware/efi/cper.c | 15 ++++++++++++---
>  include/linux/cper.h        | 22 +++++++++++++++++++++-
>  2 files changed, 33 insertions(+), 4 deletions(-)

Pulled, thanks Matt!

	Ingo

Re: [GIT PULL] EFI urgent fix

[Ingo Molnar]

* Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:

> Folks,
> 
> Please pull the following fix from Tony that addresses a bug in the EFI
> CPER driver preventing it from working with memory error records as
> described in the UEFI 2.2 spec.
> 
> The following changes since commit d67e199611b986b345ea3087ee2e4a15da1c98b3:
> 
>   efi: Fix error handling in add_sysfs_runtime_map_entry() (2015-05-05 16:20:13 +0100)
> 
> 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 4c62360d7562a20c996836d163259c87d9378120:
> 
>   efi: Handle memory error structures produced based on old versions of standard (2015-07-15 13:30:38 +0100)
> 
> ----------------------------------------------------------------
>  * Fix a bug in the Common Platform Error Record (CPER) driver that
>    caused old UEFI spec (< 2.3) versions of the memory error record
>    structure to be declared invalid - Tony Luck
> 
> ----------------------------------------------------------------
> Tony Luck (1):
>       efi: Handle memory error structures produced based on old versions of standard
> 
>  drivers/firmware/efi/cper.c | 15 ++++++++++++---
>  include/linux/cper.h        | 22 +++++++++++++++++++++-
>  2 files changed, 33 insertions(+), 4 deletions(-)

Pulled, thanks Matt!

	Ingo

[GIT PULL] EFI urgent fix

[Matt Fleming]

Folks,

Please pull the following fix from Tony that addresses a bug in the EFI
CPER driver preventing it from working with memory error records as
described in the UEFI 2.2 spec.

The following changes since commit d67e199611b986b345ea3087ee2e4a15da1c98b3:

  efi: Fix error handling in add_sysfs_runtime_map_entry() (2015-05-05 16:20:13 +0100)

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 4c62360d7562a20c996836d163259c87d9378120:

  efi: Handle memory error structures produced based on old versions of standard (2015-07-15 13:30:38 +0100)

----------------------------------------------------------------
 * Fix a bug in the Common Platform Error Record (CPER) driver that
   caused old UEFI spec (< 2.3) versions of the memory error record
   structure to be declared invalid - Tony Luck

----------------------------------------------------------------
Tony Luck (1):
      efi: Handle memory error structures produced based on old versions of standard

 drivers/firmware/efi/cper.c | 15 ++++++++++++---
 include/linux/cper.h        | 22 +++++++++++++++++++++-
 2 files changed, 33 insertions(+), 4 deletions(-)

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [GIT PULL] EFI urgent fix

[Matt Fleming]

On Thu, 11 Jun, at 04:43:58PM, Ingo Molnar wrote:
> 
> So I pulled this into tip:x86/efi, not into tip:x86/urgent, because the commit 
> that broke the ia64 build is not upstream yet.

Thanks Ingo, that sounds good to me.

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [GIT PULL] EFI urgent fix

[Matt Fleming]

On Thu, 11 Jun, at 04:43:58PM, Ingo Molnar wrote:
> 
> So I pulled this into tip:x86/efi, not into tip:x86/urgent, because the commit 
> that broke the ia64 build is not upstream yet.

Thanks Ingo, that sounds good to me.

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [GIT PULL] EFI urgent fix

[Ingo Molnar]

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

> Folks, please pull the following build fix from Peter Jones. Guenter
> reported that the ESRT driver doesn't build properly on ia64. The
> problem was discovered in linux-next.
> 
> The following changes since commit c208358c2cc832eeb5b341a465eee30be19cd5a0:
> 
>   efi: Add 'systab' information to Documentation/ABI (2015-05-27 15:40:20 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-next
> 
> for you to fetch changes up to 3846c15820a1841225d0245afda4875af23dfbbe:
> 
>   efi: Work around ia64 build problem with ESRT driver (2015-06-08 10:51:31 +0100)
> 
> ----------------------------------------------------------------
>  * Fix ESRT build breakage on ia64 reported by Guenter Roeck - Peter Jones
> 
> ----------------------------------------------------------------
> Peter Jones (1):
>       efi: Work around ia64 build problem with ESRT driver
> 
>  drivers/firmware/efi/Kconfig  | 5 +++++
>  drivers/firmware/efi/Makefile | 3 ++-
>  include/linux/efi.h           | 4 ++++
>  3 files changed, 11 insertions(+), 1 deletion(-)

So I pulled this into tip:x86/efi, not into tip:x86/urgent, because the commit 
that broke the ia64 build is not upstream yet.

Thanks,

	Ingo

Re: [GIT PULL] EFI urgent fix

[Ingo Molnar]

* Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:

> Folks, please pull the following build fix from Peter Jones. Guenter
> reported that the ESRT driver doesn't build properly on ia64. The
> problem was discovered in linux-next.
> 
> The following changes since commit c208358c2cc832eeb5b341a465eee30be19cd5a0:
> 
>   efi: Add 'systab' information to Documentation/ABI (2015-05-27 15:40:20 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-next
> 
> for you to fetch changes up to 3846c15820a1841225d0245afda4875af23dfbbe:
> 
>   efi: Work around ia64 build problem with ESRT driver (2015-06-08 10:51:31 +0100)
> 
> ----------------------------------------------------------------
>  * Fix ESRT build breakage on ia64 reported by Guenter Roeck - Peter Jones
> 
> ----------------------------------------------------------------
> Peter Jones (1):
>       efi: Work around ia64 build problem with ESRT driver
> 
>  drivers/firmware/efi/Kconfig  | 5 +++++
>  drivers/firmware/efi/Makefile | 3 ++-
>  include/linux/efi.h           | 4 ++++
>  3 files changed, 11 insertions(+), 1 deletion(-)

So I pulled this into tip:x86/efi, not into tip:x86/urgent, because the commit 
that broke the ia64 build is not upstream yet.

Thanks,

	Ingo

[GIT PULL] EFI urgent fix

[Matt Fleming]

Folks, please pull the following build fix from Peter Jones. Guenter
reported that the ESRT driver doesn't build properly on ia64. The
problem was discovered in linux-next.

The following changes since commit c208358c2cc832eeb5b341a465eee30be19cd5a0:

  efi: Add 'systab' information to Documentation/ABI (2015-05-27 15:40:20 +0100)

are available in the git repository at:

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

for you to fetch changes up to 3846c15820a1841225d0245afda4875af23dfbbe:

  efi: Work around ia64 build problem with ESRT driver (2015-06-08 10:51:31 +0100)

----------------------------------------------------------------
 * Fix ESRT build breakage on ia64 reported by Guenter Roeck - Peter Jones

----------------------------------------------------------------
Peter Jones (1):
      efi: Work around ia64 build problem with ESRT driver

 drivers/firmware/efi/Kconfig  | 5 +++++
 drivers/firmware/efi/Makefile | 3 ++-
 include/linux/efi.h           | 4 ++++
 3 files changed, 11 insertions(+), 1 deletion(-)

-- 
Matt Fleming, Intel Open Source Technology Center

[GIT PULL] EFI urgent fix

[Matt Fleming]

Folks,

Please pull the following fix from Jean which addresses an integer
overflow issue when calculating the number of entries in an SMBIOS 3.0
DMI table.

The following changes since commit 6d9ff473317245e3e5cd9922b4520411c2296388:

  firmware: dmi_scan: Fix dmi_len type (2015-02-24 18:54:17 +0000)

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 bfbaafae8519d82d10da6abe75f5766dd5b20475:

  firmware: dmi_scan: Prevent dmi_num integer overflow (2015-03-27 10:53:46 +0000)

----------------------------------------------------------------
Jean Delvare (1):
      firmware: dmi_scan: Prevent dmi_num integer overflow

 drivers/firmware/dmi_scan.c | 22 +++++++---------------
 1 file changed, 7 insertions(+), 15 deletions(-)

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [GIT PULL] EFI urgent fix

[Ingo Molnar]

* Matt Fleming <matt@console-pimps.org> wrote:

> Hi guys,
> 
> Please consider pulling the following urgent fix from Dave. It fixes an
> earlyprintk=efi regression introduced in v3.16. Due to changes in the
> early ACPI code we run out of early_ioremap slots when earlyprintk=efi
> is specified on the command line, resulting in a hang during kernel
> boot.
> 
> This patch is clearly a core x86 change, but since it is a fix for an
> EFI code issue I picked it up in my urgent queue. Let me know if you'd
> like to route this some other way.
> 
> The following changes since commit 0ceac9e094b065fe3fec19669740f338d3480498:
> 
>   efi/arm64: Fix fdt-related memory reservation (2014-09-09 07:51:09 +0100)
> 
> 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 3eddc69ffeba092d288c386646bfa5ec0fce25fd:
> 
>   x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8 (2014-09-14 15:24:31 +0100)
> 
> ----------------------------------------------------------------
>  * Increase the number of early_ioremap slots to fix a regression with
>    earlyprintk=efi after recent changes to the ACPI code - Dave Young
> 
> ----------------------------------------------------------------
> Dave Young (1):
>       x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8
> 
>  arch/x86/include/asm/fixmap.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Pulled, thanks a lot Matt!

	Ingo

[GIT PULL] EFI urgent fix

[Matt Fleming]

Hi guys,

Please consider pulling the following urgent fix from Dave. It fixes an
earlyprintk=efi regression introduced in v3.16. Due to changes in the
early ACPI code we run out of early_ioremap slots when earlyprintk=efi
is specified on the command line, resulting in a hang during kernel
boot.

This patch is clearly a core x86 change, but since it is a fix for an
EFI code issue I picked it up in my urgent queue. Let me know if you'd
like to route this some other way.

The following changes since commit 0ceac9e094b065fe3fec19669740f338d3480498:

  efi/arm64: Fix fdt-related memory reservation (2014-09-09 07:51:09 +0100)

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 3eddc69ffeba092d288c386646bfa5ec0fce25fd:

  x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8 (2014-09-14 15:24:31 +0100)

----------------------------------------------------------------
 * Increase the number of early_ioremap slots to fix a regression with
   earlyprintk=efi after recent changes to the ACPI code - Dave Young

----------------------------------------------------------------
Dave Young (1):
      x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8

 arch/x86/include/asm/fixmap.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
Matt Fleming, Intel Open Source Technology Center

[GIT PULL] EFI urgent fix

[Matt Fleming]

Hi guys,

Please consider pulling the following urgent fix from Dave. It fixes an
earlyprintk=efi regression introduced in v3.16. Due to changes in the
early ACPI code we run out of early_ioremap slots when earlyprintk=efi
is specified on the command line, resulting in a hang during kernel
boot.

This patch is clearly a core x86 change, but since it is a fix for an
EFI code issue I picked it up in my urgent queue. Let me know if you'd
like to route this some other way.

The following changes since commit 0ceac9e094b065fe3fec19669740f338d3480498:

  efi/arm64: Fix fdt-related memory reservation (2014-09-09 07:51:09 +0100)

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 3eddc69ffeba092d288c386646bfa5ec0fce25fd:

  x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8 (2014-09-14 15:24:31 +0100)

----------------------------------------------------------------
 * Increase the number of early_ioremap slots to fix a regression with
   earlyprintk=efi after recent changes to the ACPI code - Dave Young

----------------------------------------------------------------
Dave Young (1):
      x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8

 arch/x86/include/asm/fixmap.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
Matt Fleming, Intel Open Source Technology Center

[GIT PULL] EFI urgent fix

[Matt Fleming]

Folks, please pull the following fix. It's something that Peter and I
talked about a while ago, and it seems that people are actually hitting
issues without this patch and have been since v3.13.

The following changes since commit c7fb93ec51d462ec3540a729ba446663c26a0505:

  x86/efi: Include a .bss section within the PE/COFF headers (2014-07-10 14:21:39 +0100)

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 7b2a583afb4ab894f78bc0f8bd136e96b6499a7e:

  x86/efi: Enforce CONFIG_RELOCATABLE for EFI boot stub (2014-08-05 22:01:04 +0100)

----------------------------------------------------------------
 * Enforce CONFIG_RELOCATABLE for the x86 EFI boot stub, otherwise
   it's possible to overwrite random pieces of unallocated memory during
   kernel decompression, leading to machine resets.

----------------------------------------------------------------
Matt Fleming (1):
      x86/efi: Enforce CONFIG_RELOCATABLE for EFI boot stub

 arch/x86/Kconfig | 1 +
 1 file changed, 1 insertion(+)

-- 
Matt Fleming, Intel Open Source Technology Center

[GIT PULL] EFI urgent fix

[Matt Fleming]

Folks, please pull the following fix. It's something that Peter and I
talked about a while ago, and it seems that people are actually hitting
issues without this patch and have been since v3.13.

The following changes since commit c7fb93ec51d462ec3540a729ba446663c26a0505:

  x86/efi: Include a .bss section within the PE/COFF headers (2014-07-10 14:21:39 +0100)

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 7b2a583afb4ab894f78bc0f8bd136e96b6499a7e:

  x86/efi: Enforce CONFIG_RELOCATABLE for EFI boot stub (2014-08-05 22:01:04 +0100)

----------------------------------------------------------------
 * Enforce CONFIG_RELOCATABLE for the x86 EFI boot stub, otherwise
   it's possible to overwrite random pieces of unallocated memory during
   kernel decompression, leading to machine resets.

----------------------------------------------------------------
Matt Fleming (1):
      x86/efi: Enforce CONFIG_RELOCATABLE for EFI boot stub

 arch/x86/Kconfig | 1 +
 1 file changed, 1 insertion(+)

-- 
Matt Fleming, Intel Open Source Technology Center

[GIT PULL] EFI urgent fix

[Matt Fleming]

Guys, please pull the following fix from Ard that stops the arm64 EFI
stub being rebuilt on every arm64 kernel build by removing the
dependency on the generated header files.

The following changes since commit 783ee43118dc773bc8b0342c5b230e017d5a04d0:

  efi-pstore: Fix an overflow on 32-bit builds (2014-06-27 07:30:32 +0100)

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 a55c072dfe520f8fa03cf11b07b9268a8a17820a:

  efi/arm64: efistub: remove local copy of linux_banner (2014-07-07 07:26:02 +0100)

----------------------------------------------------------------
 * Remove a duplicate copy of linux_banner from the arm64 EFI stub
   which, apart from reducing code duplication also stops the arm64 stub
   being rebuilt every time make is invoked - Ard Biesheuvel

----------------------------------------------------------------
Ard Biesheuvel (1):
      efi/arm64: efistub: remove local copy of linux_banner

 arch/arm64/kernel/efi-stub.c |  2 --
 drivers/firmware/efi/fdt.c   | 10 ----------
 2 files changed, 12 deletions(-)

-- 
Matt Fleming, Intel Open Source Technology Center

[GIT PULL] EFI urgent fix

[Matt Fleming]

Guys, please pull the following fix from Ard that stops the arm64 EFI
stub being rebuilt on every arm64 kernel build by removing the
dependency on the generated header files.

The following changes since commit 783ee43118dc773bc8b0342c5b230e017d5a04d0:

  efi-pstore: Fix an overflow on 32-bit builds (2014-06-27 07:30:32 +0100)

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 a55c072dfe520f8fa03cf11b07b9268a8a17820a:

  efi/arm64: efistub: remove local copy of linux_banner (2014-07-07 07:26:02 +0100)

----------------------------------------------------------------
 * Remove a duplicate copy of linux_banner from the arm64 EFI stub
   which, apart from reducing code duplication also stops the arm64 stub
   being rebuilt every time make is invoked - Ard Biesheuvel

----------------------------------------------------------------
Ard Biesheuvel (1):
      efi/arm64: efistub: remove local copy of linux_banner

 arch/arm64/kernel/efi-stub.c |  2 --
 drivers/firmware/efi/fdt.c   | 10 ----------
 2 files changed, 12 deletions(-)

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [GIT PULL] EFI urgent fix

[Matt Fleming]

On Fri, 20 Jun, at 10:00:08AM, Matt Fleming wrote:
> Guys,
> 
> Please pull the following compiler warning fix. Sorry, I've been pretty
> slow in getting this pull request sent. Multiple people have reported
> hitting it and I've now received 4 patches for the same warning,
> 
>   http://article.gmane.org/gmane.linux.kernel.efi/4024
>   http://article.gmane.org/gmane.linux.kernel.efi/4017
>   http://article.gmane.org/gmane.linux.kernel.efi/3957
>   http://article.gmane.org/gmane.linux.kernel.efi/3930
> 
> The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
> 
>   Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
> 
> 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 6fb8cc82c096fd5ccf277678639193cae07125a0:
> 
>   efi: Fix compiler warnings (unused, const, type) (2014-06-19 15:03:05 +0100)
> 
> ----------------------------------------------------------------
>  * Fix a few compiler warnings in the arm64 EFI code that lots of people
>    are running into and reporting - Catalin Marinas

Ping? This doesn't seem to have been picked up yet?

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [GIT PULL] EFI urgent fix

[Matt Fleming]

On Fri, 20 Jun, at 10:00:08AM, Matt Fleming wrote:
> Guys,
> 
> Please pull the following compiler warning fix. Sorry, I've been pretty
> slow in getting this pull request sent. Multiple people have reported
> hitting it and I've now received 4 patches for the same warning,
> 
>   http://article.gmane.org/gmane.linux.kernel.efi/4024
>   http://article.gmane.org/gmane.linux.kernel.efi/4017
>   http://article.gmane.org/gmane.linux.kernel.efi/3957
>   http://article.gmane.org/gmane.linux.kernel.efi/3930
> 
> The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
> 
>   Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
> 
> 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 6fb8cc82c096fd5ccf277678639193cae07125a0:
> 
>   efi: Fix compiler warnings (unused, const, type) (2014-06-19 15:03:05 +0100)
> 
> ----------------------------------------------------------------
>  * Fix a few compiler warnings in the arm64 EFI code that lots of people
>    are running into and reporting - Catalin Marinas

Ping? This doesn't seem to have been picked up yet?

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [GIT PULL] EFI urgent fix

[Leif Lindholm]

On Fri, Jun 20, 2014 at 02:49:38PM +0100, Matt Fleming wrote:
> On Fri, 20 Jun, at 02:39:19PM, Leif Lindholm wrote:
> > 
> > I did post an alternative patch for one half of this a week before
> > anyone else, but that one seems to have been ignored, even by gmane:
> > http://www.spinics.net/lists/linux-efi/msg03924.html
>  
> Sorry Leif, I don't know why I didn't pick that one up. I do see it in
> my mail archive. Chalk it up to human error.

Well, it seemed to manage to trick at least one computer too...

> > That form will still be required for the 32-bit arm support, since
> > strncmp is not available in the zImage.
> 
> Are you planning on incorporating this fix into the 32-bit arm support
> patch series

Yeah, I'll do that.
Just as soon as I get back off holiday :)

/
    Leif

Re: [GIT PULL] EFI urgent fix

[Matt Fleming]

On Fri, 20 Jun, at 02:39:19PM, Leif Lindholm wrote:
> 
> I did post an alternative patch for one half of this a week before
> anyone else, but that one seems to have been ignored, even by gmane:
> http://www.spinics.net/lists/linux-efi/msg03924.html
 
Sorry Leif, I don't know why I didn't pick that one up. I do see it in
my mail archive. Chalk it up to human error.

> That form will still be required for the 32-bit arm support, since
> strncmp is not available in the zImage.

Are you planning on incorporating this fix into the 32-bit arm support
patch series

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [GIT PULL] EFI urgent fix

[Leif Lindholm]

On Fri, Jun 20, 2014 at 10:28:48AM +0100, Catalin Marinas wrote:
> On Fri, Jun 20, 2014 at 10:00:08AM +0100, Matt Fleming wrote:
> > Please pull the following compiler warning fix. Sorry, I've been pretty
> > slow in getting this pull request sent. Multiple people have reported
> > hitting it and I've now received 4 patches for the same warning,
> 
> BTW, one of them is not just a simple warning but a bug. Pointer to
> "long" variable on the stack passed to a function that only takes a
> pointer to "int". We are probably lucky that we don't hit the bug on
> arm64.
> 
> Anyway, thanks for pushing the fix.
> 
> (and lesson learnt not to trust the ARM EFI_STUB developers, won't name
> them, with properly testing their code ;))

The code was tested and showed no runtime problems - but I did manage
to miss the warnings.

I did post an alternative patch for one half of this a week before
anyone else, but that one seems to have been ignored, even by gmane:
http://www.spinics.net/lists/linux-efi/msg03924.html

That form will still be required for the 32-bit arm support, since
strncmp is not available in the zImage.

/
    Leif

Re: [GIT PULL] EFI urgent fix

[Leif Lindholm]

On Fri, Jun 20, 2014 at 10:28:48AM +0100, Catalin Marinas wrote:
> On Fri, Jun 20, 2014 at 10:00:08AM +0100, Matt Fleming wrote:
> > Please pull the following compiler warning fix. Sorry, I've been pretty
> > slow in getting this pull request sent. Multiple people have reported
> > hitting it and I've now received 4 patches for the same warning,
> 
> BTW, one of them is not just a simple warning but a bug. Pointer to
> "long" variable on the stack passed to a function that only takes a
> pointer to "int". We are probably lucky that we don't hit the bug on
> arm64.
> 
> Anyway, thanks for pushing the fix.
> 
> (and lesson learnt not to trust the ARM EFI_STUB developers, won't name
> them, with properly testing their code ;))

The code was tested and showed no runtime problems - but I did manage
to miss the warnings.

I did post an alternative patch for one half of this a week before
anyone else, but that one seems to have been ignored, even by gmane:
http://www.spinics.net/lists/linux-efi/msg03924.html

That form will still be required for the 32-bit arm support, since
strncmp is not available in the zImage.

/
    Leif

Re: [GIT PULL] EFI urgent fix

[Catalin Marinas]

On Fri, Jun 20, 2014 at 10:00:08AM +0100, Matt Fleming wrote:
> Please pull the following compiler warning fix. Sorry, I've been pretty
> slow in getting this pull request sent. Multiple people have reported
> hitting it and I've now received 4 patches for the same warning,

BTW, one of them is not just a simple warning but a bug. Pointer to
"long" variable on the stack passed to a function that only takes a
pointer to "int". We are probably lucky that we don't hit the bug on
arm64.

Anyway, thanks for pushing the fix.

(and lesson learnt not to trust the ARM EFI_STUB developers, won't name
them, with properly testing their code ;))

-- 
Catalin

Re: [GIT PULL] EFI urgent fix

[Catalin Marinas]

On Fri, Jun 20, 2014 at 10:00:08AM +0100, Matt Fleming wrote:
> Please pull the following compiler warning fix. Sorry, I've been pretty
> slow in getting this pull request sent. Multiple people have reported
> hitting it and I've now received 4 patches for the same warning,

BTW, one of them is not just a simple warning but a bug. Pointer to
"long" variable on the stack passed to a function that only takes a
pointer to "int". We are probably lucky that we don't hit the bug on
arm64.

Anyway, thanks for pushing the fix.

(and lesson learnt not to trust the ARM EFI_STUB developers, won't name
them, with properly testing their code ;))

-- 
Catalin

[GIT PULL] EFI urgent fix

[Matt Fleming]

Guys,

Please pull the following compiler warning fix. Sorry, I've been pretty
slow in getting this pull request sent. Multiple people have reported
hitting it and I've now received 4 patches for the same warning,

  http://article.gmane.org/gmane.linux.kernel.efi/4024
  http://article.gmane.org/gmane.linux.kernel.efi/4017
  http://article.gmane.org/gmane.linux.kernel.efi/3957
  http://article.gmane.org/gmane.linux.kernel.efi/3930

The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:

  Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)

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 6fb8cc82c096fd5ccf277678639193cae07125a0:

  efi: Fix compiler warnings (unused, const, type) (2014-06-19 15:03:05 +0100)

----------------------------------------------------------------
 * Fix a few compiler warnings in the arm64 EFI code that lots of people
   are running into and reporting - Catalin Marinas

----------------------------------------------------------------
Catalin Marinas (1):
      efi: Fix compiler warnings (unused, const, type)

 drivers/firmware/efi/efi.c | 6 +++---
 drivers/firmware/efi/fdt.c | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [GIT PULL] EFI urgent fix

[Ingo Molnar]

* Matt Fleming <matt@console-pimps.org> wrote:

> Folks, please pull the following patch from Dave that fixes some bugs in
> the EFI earlyprintk code when using ",keep".
> 
> The following changes since commit 47514c996fac5e6f13ef3a4c5e23f1c5cffabb7b:
> 
>   efi: Pass correct file handle to efi_file_{read,close} (2014-04-10 21:20:03 +0100)
> 
> 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 5f35eb0e29ca26da82febe49d7698dbeb8882ea0:
> 
>   x86/efi: earlyprintk=efi,keep fix (2014-05-03 06:39:06 +0100)
> 
> ----------------------------------------------------------------
>  * Fix earlyprintk=efi,keep support by switching to an ioremap() mapping
>    of the framebuffer when early_ioremap() is no longer available and
>    dropping __init from functions that may be invoked after
>    free_initmem() - Dave Young
> 
> ----------------------------------------------------------------
> Dave Young (1):
>       x86/efi: earlyprintk=efi,keep fix
> 
>  arch/x86/platform/efi/early_printk.c | 83 +++++++++++++++++++++++++++---------
>  1 file changed, 64 insertions(+), 19 deletions(-)

Pulled into tip:x86/urgent, thanks a lot Matt!

	Ingo

Re: [GIT PULL] EFI urgent fix

[Ingo Molnar]

* Matt Fleming <matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org> wrote:

> Folks, please pull the following patch from Dave that fixes some bugs in
> the EFI earlyprintk code when using ",keep".
> 
> The following changes since commit 47514c996fac5e6f13ef3a4c5e23f1c5cffabb7b:
> 
>   efi: Pass correct file handle to efi_file_{read,close} (2014-04-10 21:20:03 +0100)
> 
> 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 5f35eb0e29ca26da82febe49d7698dbeb8882ea0:
> 
>   x86/efi: earlyprintk=efi,keep fix (2014-05-03 06:39:06 +0100)
> 
> ----------------------------------------------------------------
>  * Fix earlyprintk=efi,keep support by switching to an ioremap() mapping
>    of the framebuffer when early_ioremap() is no longer available and
>    dropping __init from functions that may be invoked after
>    free_initmem() - Dave Young
> 
> ----------------------------------------------------------------
> Dave Young (1):
>       x86/efi: earlyprintk=efi,keep fix
> 
>  arch/x86/platform/efi/early_printk.c | 83 +++++++++++++++++++++++++++---------
>  1 file changed, 64 insertions(+), 19 deletions(-)

Pulled into tip:x86/urgent, thanks a lot Matt!

	Ingo

[GIT PULL] EFI urgent fix

[Matt Fleming]

Folks, please pull the following patch from Dave that fixes some bugs in
the EFI earlyprintk code when using ",keep".

The following changes since commit 47514c996fac5e6f13ef3a4c5e23f1c5cffabb7b:

  efi: Pass correct file handle to efi_file_{read,close} (2014-04-10 21:20:03 +0100)

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 5f35eb0e29ca26da82febe49d7698dbeb8882ea0:

  x86/efi: earlyprintk=efi,keep fix (2014-05-03 06:39:06 +0100)

----------------------------------------------------------------
 * Fix earlyprintk=efi,keep support by switching to an ioremap() mapping
   of the framebuffer when early_ioremap() is no longer available and
   dropping __init from functions that may be invoked after
   free_initmem() - Dave Young

----------------------------------------------------------------
Dave Young (1):
      x86/efi: earlyprintk=efi,keep fix

 arch/x86/platform/efi/early_printk.c | 83 +++++++++++++++++++++++++++---------
 1 file changed, 64 insertions(+), 19 deletions(-)

-- 
Matt Fleming, Intel Open Source Technology Center

[GIT PULL] EFI urgent fix

[Matt Fleming]

Folks, please pull the following patch from Dave that fixes some bugs in
the EFI earlyprintk code when using ",keep".

The following changes since commit 47514c996fac5e6f13ef3a4c5e23f1c5cffabb7b:

  efi: Pass correct file handle to efi_file_{read,close} (2014-04-10 21:20:03 +0100)

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 5f35eb0e29ca26da82febe49d7698dbeb8882ea0:

  x86/efi: earlyprintk=efi,keep fix (2014-05-03 06:39:06 +0100)

----------------------------------------------------------------
 * Fix earlyprintk=efi,keep support by switching to an ioremap() mapping
   of the framebuffer when early_ioremap() is no longer available and
   dropping __init from functions that may be invoked after
   free_initmem() - Dave Young

----------------------------------------------------------------
Dave Young (1):
      x86/efi: earlyprintk=efi,keep fix

 arch/x86/platform/efi/early_printk.c | 83 +++++++++++++++++++++++++++---------
 1 file changed, 64 insertions(+), 19 deletions(-)

-- 
Matt Fleming, Intel Open Source Technology Center

[GIT PULL] EFI urgent fix

[Matt Fleming]

Please pull the following fix from Borislav that fixes a boot regression
for SGI UV.

The following changes since commit 09503379dc99535b1bbfa51aa1aeef340f5d82ec:

  x86/efi: Check status field to validate BGRT header (2014-02-14 10:07:15 +0000)

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 a5d90c923bcfb9632d998ed06e9569216ad695f3:

  x86/efi: Quirk out SGI UV (2014-03-04 23:43:33 +0000)

----------------------------------------------------------------
 * Disable the new EFI 1:1 virtual mapping for SGI UV because using it
   causes a crash during boot - Borislav Petkov

----------------------------------------------------------------
Borislav Petkov (1):
      x86/efi: Quirk out SGI UV

 arch/x86/include/asm/efi.h  |  1 +
 arch/x86/kernel/setup.c     | 10 ++--------
 arch/x86/platform/efi/efi.c | 20 ++++++++++++++++++++
 3 files changed, 23 insertions(+), 8 deletions(-)

-- 
Matt Fleming, Intel Open Source Technology Center

[GIT PULL] EFI urgent fix

[Matt Fleming]

Please pull the following fix from Borislav that fixes a boot regression
for SGI UV.

The following changes since commit 09503379dc99535b1bbfa51aa1aeef340f5d82ec:

  x86/efi: Check status field to validate BGRT header (2014-02-14 10:07:15 +0000)

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 a5d90c923bcfb9632d998ed06e9569216ad695f3:

  x86/efi: Quirk out SGI UV (2014-03-04 23:43:33 +0000)

----------------------------------------------------------------
 * Disable the new EFI 1:1 virtual mapping for SGI UV because using it
   causes a crash during boot - Borislav Petkov

----------------------------------------------------------------
Borislav Petkov (1):
      x86/efi: Quirk out SGI UV

 arch/x86/include/asm/efi.h  |  1 +
 arch/x86/kernel/setup.c     | 10 ++--------
 arch/x86/platform/efi/efi.c | 20 ++++++++++++++++++++
 3 files changed, 23 insertions(+), 8 deletions(-)

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [GIT PULL] EFI urgent fix

[Ingo Molnar]

* Matt Fleming <matt@console-pimps.org> wrote:

> Hi,
> 
> The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:
> 
>   Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)
> 
> 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 700870119f49084da004ab588ea2b799689efaf7:
> 
>   x86, efi: Don't map Boot Services on i386 (2013-09-18 14:42:33 +0100)
> 
> ----------------------------------------------------------------
>  * Fix WARNING on i386 by only enabling a workaround for x86-64 since
>    we've never encountered the bug on i386 - Josh Boyer
> 
> ----------------------------------------------------------------
> Josh Boyer (1):
>       x86, efi: Don't map Boot Services on i386
> 
>  arch/x86/platform/efi/efi.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)

Pulled into tip:x86/urgent, thanks Matt!

	Ingo

Re: [GIT PULL] EFI urgent fix

[Ingo Molnar]

* Matt Fleming <matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org> wrote:

> Hi,
> 
> The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:
> 
>   Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)
> 
> 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 700870119f49084da004ab588ea2b799689efaf7:
> 
>   x86, efi: Don't map Boot Services on i386 (2013-09-18 14:42:33 +0100)
> 
> ----------------------------------------------------------------
>  * Fix WARNING on i386 by only enabling a workaround for x86-64 since
>    we've never encountered the bug on i386 - Josh Boyer
> 
> ----------------------------------------------------------------
> Josh Boyer (1):
>       x86, efi: Don't map Boot Services on i386
> 
>  arch/x86/platform/efi/efi.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)

Pulled into tip:x86/urgent, thanks Matt!

	Ingo

[GIT PULL] EFI urgent fix

[Matt Fleming]

Hi,

The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:

  Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)

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 700870119f49084da004ab588ea2b799689efaf7:

  x86, efi: Don't map Boot Services on i386 (2013-09-18 14:42:33 +0100)

----------------------------------------------------------------
 * Fix WARNING on i386 by only enabling a workaround for x86-64 since
   we've never encountered the bug on i386 - Josh Boyer

----------------------------------------------------------------
Josh Boyer (1):
      x86, efi: Don't map Boot Services on i386

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

-- 
Matt Fleming, Intel Open Source Technology Center

[GIT PULL] EFI urgent fix

[Matt Fleming]

Hi,

The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:

  Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)

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 700870119f49084da004ab588ea2b799689efaf7:

  x86, efi: Don't map Boot Services on i386 (2013-09-18 14:42:33 +0100)

----------------------------------------------------------------
 * Fix WARNING on i386 by only enabling a workaround for x86-64 since
   we've never encountered the bug on i386 - Josh Boyer

----------------------------------------------------------------
Josh Boyer (1):
      x86, efi: Don't map Boot Services on i386

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

-- 
Matt Fleming, Intel Open Source Technology Center

[GIT PULL] EFI urgent fix

[Matt Fleming]

The following changes since commit f8b8404337de4e2466e2e1139ea68b1f8295974f:

  Modify UEFI anti-bricking code (2013-06-10 21:59:37 +0100)

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 b8cb62f82103083a6e8fa5470bfe634a2c06514d:

  x86/efi: Fix dummy variable buffer allocation (2013-06-21 10:52:49 +0100)

----------------------------------------------------------------
 * Don't leak random kernel memory to EFI variable NVRAM when attempting
   to initiate garbage collection. Also, free the kernel memory when
   we're done with it instead of leaking - Ben Hutchings

----------------------------------------------------------------
Ben Hutchings (1):
      x86/efi: Fix dummy variable buffer allocation

 arch/x86/platform/efi/efi.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

-- 
Matt Fleming, Intel Open Source Technology Center

[GIT PULL] EFI urgent fix

[Matt Fleming]

The following changes since commit f8b8404337de4e2466e2e1139ea68b1f8295974f:

  Modify UEFI anti-bricking code (2013-06-10 21:59:37 +0100)

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 b8cb62f82103083a6e8fa5470bfe634a2c06514d:

  x86/efi: Fix dummy variable buffer allocation (2013-06-21 10:52:49 +0100)

----------------------------------------------------------------
 * Don't leak random kernel memory to EFI variable NVRAM when attempting
   to initiate garbage collection. Also, free the kernel memory when
   we're done with it instead of leaking - Ben Hutchings

----------------------------------------------------------------
Ben Hutchings (1):
      x86/efi: Fix dummy variable buffer allocation

 arch/x86/platform/efi/efi.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [GIT PULL] EFI urgent fix

[Matt Fleming]

On Fri, 26 Apr, at 09:40:46AM, Linus Torvalds wrote:
> On Fri, Apr 26, 2013 at 9:30 AM, Matt Fleming <matt@console-pimps.org> wrote:
> > Hi Peter, Linus,
> >
> > I've got a small patch that fixes a crash for the Google folks and their
> > EFI SMI driver, which was caused by dereferencing a garbage pointer.
> 
> Hmm. I already took this from the earlier email you sent. Did it change since?

Nope, there hasn't been any change. I just didn't know whether you
preferred to take the fix via email or a pull request.

Thanks for picking this up.

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [GIT PULL] EFI urgent fix

[Matt Fleming]

On Fri, 26 Apr, at 09:40:46AM, Linus Torvalds wrote:
> On Fri, Apr 26, 2013 at 9:30 AM, Matt Fleming <matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org> wrote:
> > Hi Peter, Linus,
> >
> > I've got a small patch that fixes a crash for the Google folks and their
> > EFI SMI driver, which was caused by dereferencing a garbage pointer.
> 
> Hmm. I already took this from the earlier email you sent. Did it change since?

Nope, there hasn't been any change. I just didn't know whether you
preferred to take the fix via email or a pull request.

Thanks for picking this up.

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [GIT PULL] EFI urgent fix

[Linus Torvalds]

On Fri, Apr 26, 2013 at 9:30 AM, Matt Fleming <matt@console-pimps.org> wrote:
> Hi Peter, Linus,
>
> I've got a small patch that fixes a crash for the Google folks and their
> EFI SMI driver, which was caused by dereferencing a garbage pointer.

Hmm. I already took this from the earlier email you sent. Did it change since?

            Linus

Re: [GIT PULL] EFI urgent fix

[Linus Torvalds]

On Fri, Apr 26, 2013 at 9:30 AM, Matt Fleming <matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org> wrote:
> Hi Peter, Linus,
>
> I've got a small patch that fixes a crash for the Google folks and their
> EFI SMI driver, which was caused by dereferencing a garbage pointer.

Hmm. I already took this from the earlier email you sent. Did it change since?

            Linus

[GIT PULL] EFI urgent fix

[Matt Fleming]

Hi Peter, Linus,

I've got a small patch that fixes a crash for the Google folks and their
EFI SMI driver, which was caused by dereferencing a garbage pointer.

Please consider pulling.

The following changes since commit f697036b93aa7345d4cbb3c854a76456c0ddac45:

  efi: Check EFI revision in setup_efi_vars (2013-04-24 16:19:01 +0100)

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 45432323ef7038a91599959173700fdb8a0adb2f:

  efivars: only check for duplicates on the registered list (2013-04-26 16:50:01 +0100)

----------------------------------------------------------------
 * Last minute bugfix for the efivars code. The google EFI SMI driver
   maintains its own list of EFI variables but the efivars core was
   directly accessing a different (and in this case, uninitialised) list
   resulting in a crash.

----------------------------------------------------------------
Matt Fleming (1):
      efivars: only check for duplicates on the registered list

 drivers/firmware/efivars.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

-- 
Matt Fleming, Intel Open Source Technology Center

[GIT PULL] EFI urgent fix

[Matt Fleming]

Hi Peter, Linus,

I've got a small patch that fixes a crash for the Google folks and their
EFI SMI driver, which was caused by dereferencing a garbage pointer.

Please consider pulling.

The following changes since commit f697036b93aa7345d4cbb3c854a76456c0ddac45:

  efi: Check EFI revision in setup_efi_vars (2013-04-24 16:19:01 +0100)

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 45432323ef7038a91599959173700fdb8a0adb2f:

  efivars: only check for duplicates on the registered list (2013-04-26 16:50:01 +0100)

----------------------------------------------------------------
 * Last minute bugfix for the efivars code. The google EFI SMI driver
   maintains its own list of EFI variables but the efivars core was
   directly accessing a different (and in this case, uninitialised) list
   resulting in a crash.

----------------------------------------------------------------
Matt Fleming (1):
      efivars: only check for duplicates on the registered list

 drivers/firmware/efivars.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

-- 
Matt Fleming, Intel Open Source Technology Center