Re: [GIT PULL] EFI urgent fixes
* Matt Fleming wrote: > Folks, please pull the following urgent EFI fixes which prevent an oops > if users pass an invalid "efi" kernel parameter and a boot issue seen on > Parallels virtual machines. > > The tag is based on v4.2-rc4, let me know if you want me to rebase it on > top of something else. > > The following changes since commit cbfe8fa6cd672011c755c3cd85c9ffd4e2d10a6f: > > Linux 4.2-rc4 (2015-07-26 12:26:21 -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 9115c7589b11349a1c3099758b4bded579ff69e0: > > efi: Check for NULL efi kernel parameters (2015-07-30 18:07:11 +0100) > > > * Fix an EFI boot issue preventing a Parallels virtual machine from >booting because the upper 32-bits of the EFI memmap pointer were >being discarded in setup_e820() - Dmitry Skorodumov > > * Validate that the "efi" kernel parameter gets used with an argument, >otherwise we will oops - Ricardo Neri > > > Dmitry Skorodumov (1): > x86/efi: Use all 64 bit of efi_memmap in setup_e820() > > Ricardo Neri (1): > efi: Check for NULL efi kernel parameters > > arch/x86/boot/compressed/eboot.c | 4 > arch/x86/platform/efi/efi.c | 5 + > drivers/firmware/efi/efi.c | 5 + > 3 files changed, 14 insertions(+) Pulled, thanks Matt! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming m...@codeblueprint.co.uk wrote: Folks, please pull the following urgent EFI fixes which prevent an oops if users pass an invalid efi kernel parameter and a boot issue seen on Parallels virtual machines. The tag is based on v4.2-rc4, let me know if you want me to rebase it on top of something else. The following changes since commit cbfe8fa6cd672011c755c3cd85c9ffd4e2d10a6f: Linux 4.2-rc4 (2015-07-26 12:26:21 -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 9115c7589b11349a1c3099758b4bded579ff69e0: efi: Check for NULL efi kernel parameters (2015-07-30 18:07:11 +0100) * Fix an EFI boot issue preventing a Parallels virtual machine from booting because the upper 32-bits of the EFI memmap pointer were being discarded in setup_e820() - Dmitry Skorodumov * Validate that the efi kernel parameter gets used with an argument, otherwise we will oops - Ricardo Neri Dmitry Skorodumov (1): x86/efi: Use all 64 bit of efi_memmap in setup_e820() Ricardo Neri (1): efi: Check for NULL efi kernel parameters arch/x86/boot/compressed/eboot.c | 4 arch/x86/platform/efi/efi.c | 5 + drivers/firmware/efi/efi.c | 5 + 3 files changed, 14 insertions(+) Pulled, thanks Matt! Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming wrote: > Folks, please pull the following bug fixes for efivarfs, EFI boot stub > and the EFI runtime map code. > > The following changes since commit bfbaafae8519d82d10da6abe75f5766dd5b20475: > > firmware: dmi_scan: Prevent dmi_num integer overflow (2015-03-27 10:53:46 > +) > > 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 d67e199611b986b345ea3087ee2e4a15da1c98b3: > > efi: Fix error handling in add_sysfs_runtime_map_entry() (2015-05-05 > 16:20:13 +0100) > > > * Avoid garbage names in efivarfs due to buggy firmware by zero'ing >EFI variable name - Ross Lagerwall > > * Stop erroneously dropping upper 32-bits of boot command line pointer >in EFI boot stub and stash them in ext_cmd_line_ptr - Roy Franz > > * Fix double-free bug in error handling code path of EFI runtime map >code - Dan Carpenter > > > Dan Carpenter (1): > efi: Fix error handling in add_sysfs_runtime_map_entry() > > Ross Lagerwall (1): > efivarfs: Ensure VariableName is NUL-terminated > > Roy Franz (1): > x86/efi: Store upper bits of command line buffer address in > ext_cmd_line_ptr > > arch/x86/boot/compressed/eboot.c | 2 ++ > drivers/firmware/efi/runtime-map.c | 6 +++--- > fs/efivarfs/super.c| 2 +- > 3 files changed, 6 insertions(+), 4 deletions(-) Pulled into tip:x86/urgent, thanks a lot Matt! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming m...@codeblueprint.co.uk wrote: Folks, please pull the following bug fixes for efivarfs, EFI boot stub and the EFI runtime map code. The following changes since commit bfbaafae8519d82d10da6abe75f5766dd5b20475: firmware: dmi_scan: Prevent dmi_num integer overflow (2015-03-27 10:53:46 +) 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 d67e199611b986b345ea3087ee2e4a15da1c98b3: efi: Fix error handling in add_sysfs_runtime_map_entry() (2015-05-05 16:20:13 +0100) * Avoid garbage names in efivarfs due to buggy firmware by zero'ing EFI variable name - Ross Lagerwall * Stop erroneously dropping upper 32-bits of boot command line pointer in EFI boot stub and stash them in ext_cmd_line_ptr - Roy Franz * Fix double-free bug in error handling code path of EFI runtime map code - Dan Carpenter Dan Carpenter (1): efi: Fix error handling in add_sysfs_runtime_map_entry() Ross Lagerwall (1): efivarfs: Ensure VariableName is NUL-terminated Roy Franz (1): x86/efi: Store upper bits of command line buffer address in ext_cmd_line_ptr arch/x86/boot/compressed/eboot.c | 2 ++ drivers/firmware/efi/runtime-map.c | 6 +++--- fs/efivarfs/super.c| 2 +- 3 files changed, 6 insertions(+), 4 deletions(-) Pulled into tip:x86/urgent, thanks a lot Matt! Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Mon, 02 Mar, at 02:24:10PM, Ingo Molnar wrote: > > Pulled, thanks Matt! > > For future reference, plase leave out unreadable commit messages like > this: > > While adding support loading kernel and initrd above 4G to grub2 in > legacy mode, I was referring to efi_high_alloc(). That will allocate > buffer for kernel and then initrd, and initrd will use kernel buffer > start as limit. > > During testing found two buffers will be overlapped when initrd size > is very big like 400M. > > I pulled it, because you do explain the commit in the second half of > the changelog, in parentheses - but instead of forcing readers through > the crappy part, please just drop the crappy explanation and fix it > up, or require your contributors to submit proper changelogs. (Yinghai > Lu is a repeat offender in that area.) Noted, I'll be sure to do this in the future. Thanks Ingo! -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming wrote: > Folks, please pull the following urgent changes. > > The following changes since commit 43a9f69692b232d1c64c913a27507eb14a1c47fd: > > Revert "efi/libstub: Call get_memory_map() to obtain map and desc sizes" > (2015-02-18 11:38:13 +) > > 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 6d9ff473317245e3e5cd9922b4520411c2296388: > > firmware: dmi_scan: Fix dmi_len type (2015-02-24 18:54:17 +) > > > * Fix regression in DMI sysfs code for handling "End of Table" entry >and a type bug that could lead to integer overflow - Ivan Khoronzhuk > > * Fix boundary checking in efi_high_alloc() which can lead to memory >corruption in the EFI boot stubs - Yinghai Lu > > > Ivan Khoronzhuk (2): > firmware: dmi_scan: Fix dmi scan to handle "End of Table" structure > firmware: dmi_scan: Fix dmi_len type > > Yinghai Lu (1): > efi/libstub: Fix boundary checking in efi_high_alloc() > > drivers/firmware/dmi_scan.c| 17 + > drivers/firmware/efi/libstub/efi-stub-helper.c | 8 > 2 files changed, 13 insertions(+), 12 deletions(-) Pulled, thanks Matt! For future reference, plase leave out unreadable commit messages like this: While adding support loading kernel and initrd above 4G to grub2 in legacy mode, I was referring to efi_high_alloc(). That will allocate buffer for kernel and then initrd, and initrd will use kernel buffer start as limit. During testing found two buffers will be overlapped when initrd size is very big like 400M. I pulled it, because you do explain the commit in the second half of the changelog, in parentheses - but instead of forcing readers through the crappy part, please just drop the crappy explanation and fix it up, or require your contributors to submit proper changelogs. (Yinghai Lu is a repeat offender in that area.) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Mon, 02 Mar, at 02:24:10PM, Ingo Molnar wrote: Pulled, thanks Matt! For future reference, plase leave out unreadable commit messages like this: While adding support loading kernel and initrd above 4G to grub2 in legacy mode, I was referring to efi_high_alloc(). That will allocate buffer for kernel and then initrd, and initrd will use kernel buffer start as limit. During testing found two buffers will be overlapped when initrd size is very big like 400M. I pulled it, because you do explain the commit in the second half of the changelog, in parentheses - but instead of forcing readers through the crappy part, please just drop the crappy explanation and fix it up, or require your contributors to submit proper changelogs. (Yinghai Lu is a repeat offender in that area.) Noted, I'll be sure to do this in the future. Thanks Ingo! -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming m...@codeblueprint.co.uk wrote: Folks, please pull the following urgent changes. The following changes since commit 43a9f69692b232d1c64c913a27507eb14a1c47fd: Revert efi/libstub: Call get_memory_map() to obtain map and desc sizes (2015-02-18 11:38:13 +) 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 6d9ff473317245e3e5cd9922b4520411c2296388: firmware: dmi_scan: Fix dmi_len type (2015-02-24 18:54:17 +) * Fix regression in DMI sysfs code for handling End of Table entry and a type bug that could lead to integer overflow - Ivan Khoronzhuk * Fix boundary checking in efi_high_alloc() which can lead to memory corruption in the EFI boot stubs - Yinghai Lu Ivan Khoronzhuk (2): firmware: dmi_scan: Fix dmi scan to handle End of Table structure firmware: dmi_scan: Fix dmi_len type Yinghai Lu (1): efi/libstub: Fix boundary checking in efi_high_alloc() drivers/firmware/dmi_scan.c| 17 + drivers/firmware/efi/libstub/efi-stub-helper.c | 8 2 files changed, 13 insertions(+), 12 deletions(-) Pulled, thanks Matt! For future reference, plase leave out unreadable commit messages like this: While adding support loading kernel and initrd above 4G to grub2 in legacy mode, I was referring to efi_high_alloc(). That will allocate buffer for kernel and then initrd, and initrd will use kernel buffer start as limit. During testing found two buffers will be overlapped when initrd size is very big like 400M. I pulled it, because you do explain the commit in the second half of the changelog, in parentheses - but instead of forcing readers through the crappy part, please just drop the crappy explanation and fix it up, or require your contributors to submit proper changelogs. (Yinghai Lu is a repeat offender in that area.) Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Ard Biesheuvel wrote:
>
> > On 18 feb. 2015, at 13:43, Ingo Molnar wrote:
> >
> >
> > * Matt Fleming wrote:
> >
> >> Folks, please pull the following fixes. The revert addresses a
> >> regression that Ard hit when booting Qemu and Xen, and the other patch
> >> ensures that we don't triple fault when receiving an NMI or MCE during
> >> an EFI mixed mode call, which may happen, for instance, when running
> >> perf.
> >>
> >> The pull is against tip/x86/efi because tip/x86/urgent doesn't contain
> >> commit d1a8d66b9177 ("efi/libstub: Call get_memory_map() to obtain map
> >> and desc sizes") needed for the revert.
> >>
> >> If you'd prefer for me to resend this after the merge window closes,
> >> just let me know.
> >>
> >> The following changes since commit
> >> 3c01b74e818a7a3b2ee9b0d584cca0bc154a031c:
> >>
> >> Merge tag 'efi-next' of
> >> git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/efi
> >> (2015-01-29 19:16: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 43a9f69692b232d1c64c913a27507eb14a1c47fd:
> >>
> >> Revert "efi/libstub: Call get_memory_map() to obtain map and desc sizes"
> >> (2015-02-18 11:38:13 +)
> >>
> >>
> >> * Leave a valid 64-bit IDT installed during runtime EFI mixed mode
> >> calls to avoid triple faults if an NMI/MCE is received.
> >>
> >> * Revert Ard's change to the libstub get_memory_map() that went into
> >> the v3.20 merge window because it causes boot regressions on Qemu and
> >> Xen.
> >>
> >>
> >> Matt Fleming (2):
> >> x86/efi: Avoid triple faults during EFI mixed mode calls
> >> Revert "efi/libstub: Call get_memory_map() to obtain map and desc
> >> sizes"
> >>
> >> arch/x86/boot/compressed/Makefile | 1 +
> >> arch/x86/boot/compressed/efi_stub_64.S | 25
> >> arch/x86/boot/compressed/efi_thunk_64.S| 196
> >> +
> >> arch/x86/platform/efi/efi_stub_64.S| 161
> >> arch/x86/platform/efi/efi_thunk_64.S | 121 ---
> >> drivers/firmware/efi/libstub/efi-stub-helper.c | 16 +-
> >> 6 files changed, 307 insertions(+), 213 deletions(-)
> >> create mode 100644 arch/x86/boot/compressed/efi_thunk_64.S
> >
> > Pulled, thanks Matt!
> >
> > Btw., I find the revert a bit sad: in most cases breaking
> > virtualized environments isn't a regression really, it's
> > _them_ who couple to the kernel in an incestuous way that
> > causes the problem: fixes should come from them ...
> >
>
> It potentially breaks physical environments as well,
> [...]
Fair enough!
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
> On 18 feb. 2015, at 13:43, Ingo Molnar wrote:
>
>
> * Matt Fleming wrote:
>
>> Folks, please pull the following fixes. The revert addresses a
>> regression that Ard hit when booting Qemu and Xen, and the other patch
>> ensures that we don't triple fault when receiving an NMI or MCE during
>> an EFI mixed mode call, which may happen, for instance, when running
>> perf.
>>
>> The pull is against tip/x86/efi because tip/x86/urgent doesn't contain
>> commit d1a8d66b9177 ("efi/libstub: Call get_memory_map() to obtain map
>> and desc sizes") needed for the revert.
>>
>> If you'd prefer for me to resend this after the merge window closes,
>> just let me know.
>>
>> The following changes since commit 3c01b74e818a7a3b2ee9b0d584cca0bc154a031c:
>>
>> Merge tag 'efi-next' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/efi
>> (2015-01-29 19:16: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 43a9f69692b232d1c64c913a27507eb14a1c47fd:
>>
>> Revert "efi/libstub: Call get_memory_map() to obtain map and desc sizes"
>> (2015-02-18 11:38:13 +)
>>
>>
>> * Leave a valid 64-bit IDT installed during runtime EFI mixed mode
>> calls to avoid triple faults if an NMI/MCE is received.
>>
>> * Revert Ard's change to the libstub get_memory_map() that went into
>> the v3.20 merge window because it causes boot regressions on Qemu and
>> Xen.
>>
>>
>> Matt Fleming (2):
>> x86/efi: Avoid triple faults during EFI mixed mode calls
>> Revert "efi/libstub: Call get_memory_map() to obtain map and desc sizes"
>>
>> arch/x86/boot/compressed/Makefile | 1 +
>> arch/x86/boot/compressed/efi_stub_64.S | 25
>> arch/x86/boot/compressed/efi_thunk_64.S| 196
>> +
>> arch/x86/platform/efi/efi_stub_64.S| 161
>> arch/x86/platform/efi/efi_thunk_64.S | 121 ---
>> drivers/firmware/efi/libstub/efi-stub-helper.c | 16 +-
>> 6 files changed, 307 insertions(+), 213 deletions(-)
>> create mode 100644 arch/x86/boot/compressed/efi_thunk_64.S
>
> Pulled, thanks Matt!
>
> Btw., I find the revert a bit sad: in most cases breaking
> virtualized environments isn't a regression really, it's
> _them_ who couple to the kernel in an incestuous way that
> causes the problem: fixes should come from them ...
>
It potentially breaks physical environments as well, it is just that i spotted
it while testing virt ports of Tianocore. And frankly, the patch wasn't
entirely correct to begin with
Regards,
Ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming wrote:
> Folks, please pull the following fixes. The revert addresses a
> regression that Ard hit when booting Qemu and Xen, and the other patch
> ensures that we don't triple fault when receiving an NMI or MCE during
> an EFI mixed mode call, which may happen, for instance, when running
> perf.
>
> The pull is against tip/x86/efi because tip/x86/urgent doesn't contain
> commit d1a8d66b9177 ("efi/libstub: Call get_memory_map() to obtain map
> and desc sizes") needed for the revert.
>
> If you'd prefer for me to resend this after the merge window closes,
> just let me know.
>
> The following changes since commit 3c01b74e818a7a3b2ee9b0d584cca0bc154a031c:
>
> Merge tag 'efi-next' of
> git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/efi
> (2015-01-29 19:16: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 43a9f69692b232d1c64c913a27507eb14a1c47fd:
>
> Revert "efi/libstub: Call get_memory_map() to obtain map and desc sizes"
> (2015-02-18 11:38:13 +)
>
>
> * Leave a valid 64-bit IDT installed during runtime EFI mixed mode
>calls to avoid triple faults if an NMI/MCE is received.
>
> * Revert Ard's change to the libstub get_memory_map() that went into
>the v3.20 merge window because it causes boot regressions on Qemu and
>Xen.
>
>
> Matt Fleming (2):
> x86/efi: Avoid triple faults during EFI mixed mode calls
> Revert "efi/libstub: Call get_memory_map() to obtain map and desc sizes"
>
> arch/x86/boot/compressed/Makefile | 1 +
> arch/x86/boot/compressed/efi_stub_64.S | 25
> arch/x86/boot/compressed/efi_thunk_64.S| 196
> +
> arch/x86/platform/efi/efi_stub_64.S| 161
> arch/x86/platform/efi/efi_thunk_64.S | 121 ---
> drivers/firmware/efi/libstub/efi-stub-helper.c | 16 +-
> 6 files changed, 307 insertions(+), 213 deletions(-)
> create mode 100644 arch/x86/boot/compressed/efi_thunk_64.S
Pulled, thanks Matt!
Btw., I find the revert a bit sad: in most cases breaking
virtualized environments isn't a regression really, it's
_them_ who couple to the kernel in an incestuous way that
causes the problem: fixes should come from them ...
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Ard Biesheuvel ard.biesheu...@linaro.org wrote: On 18 feb. 2015, at 13:43, Ingo Molnar mi...@kernel.org wrote: * Matt Fleming m...@codeblueprint.co.uk wrote: Folks, please pull the following fixes. The revert addresses a regression that Ard hit when booting Qemu and Xen, and the other patch ensures that we don't triple fault when receiving an NMI or MCE during an EFI mixed mode call, which may happen, for instance, when running perf. The pull is against tip/x86/efi because tip/x86/urgent doesn't contain commit d1a8d66b9177 (efi/libstub: Call get_memory_map() to obtain map and desc sizes) needed for the revert. If you'd prefer for me to resend this after the merge window closes, just let me know. The following changes since commit 3c01b74e818a7a3b2ee9b0d584cca0bc154a031c: Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/efi (2015-01-29 19:16: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 43a9f69692b232d1c64c913a27507eb14a1c47fd: Revert efi/libstub: Call get_memory_map() to obtain map and desc sizes (2015-02-18 11:38:13 +) * Leave a valid 64-bit IDT installed during runtime EFI mixed mode calls to avoid triple faults if an NMI/MCE is received. * Revert Ard's change to the libstub get_memory_map() that went into the v3.20 merge window because it causes boot regressions on Qemu and Xen. Matt Fleming (2): x86/efi: Avoid triple faults during EFI mixed mode calls Revert efi/libstub: Call get_memory_map() to obtain map and desc sizes arch/x86/boot/compressed/Makefile | 1 + arch/x86/boot/compressed/efi_stub_64.S | 25 arch/x86/boot/compressed/efi_thunk_64.S| 196 + arch/x86/platform/efi/efi_stub_64.S| 161 arch/x86/platform/efi/efi_thunk_64.S | 121 --- drivers/firmware/efi/libstub/efi-stub-helper.c | 16 +- 6 files changed, 307 insertions(+), 213 deletions(-) create mode 100644 arch/x86/boot/compressed/efi_thunk_64.S Pulled, thanks Matt! Btw., I find the revert a bit sad: in most cases breaking virtualized environments isn't a regression really, it's _them_ who couple to the kernel in an incestuous way that causes the problem: fixes should come from them ... It potentially breaks physical environments as well, [...] Fair enough! Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming m...@codeblueprint.co.uk wrote: Folks, please pull the following fixes. The revert addresses a regression that Ard hit when booting Qemu and Xen, and the other patch ensures that we don't triple fault when receiving an NMI or MCE during an EFI mixed mode call, which may happen, for instance, when running perf. The pull is against tip/x86/efi because tip/x86/urgent doesn't contain commit d1a8d66b9177 (efi/libstub: Call get_memory_map() to obtain map and desc sizes) needed for the revert. If you'd prefer for me to resend this after the merge window closes, just let me know. The following changes since commit 3c01b74e818a7a3b2ee9b0d584cca0bc154a031c: Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/efi (2015-01-29 19:16: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 43a9f69692b232d1c64c913a27507eb14a1c47fd: Revert efi/libstub: Call get_memory_map() to obtain map and desc sizes (2015-02-18 11:38:13 +) * Leave a valid 64-bit IDT installed during runtime EFI mixed mode calls to avoid triple faults if an NMI/MCE is received. * Revert Ard's change to the libstub get_memory_map() that went into the v3.20 merge window because it causes boot regressions on Qemu and Xen. Matt Fleming (2): x86/efi: Avoid triple faults during EFI mixed mode calls Revert efi/libstub: Call get_memory_map() to obtain map and desc sizes arch/x86/boot/compressed/Makefile | 1 + arch/x86/boot/compressed/efi_stub_64.S | 25 arch/x86/boot/compressed/efi_thunk_64.S| 196 + arch/x86/platform/efi/efi_stub_64.S| 161 arch/x86/platform/efi/efi_thunk_64.S | 121 --- drivers/firmware/efi/libstub/efi-stub-helper.c | 16 +- 6 files changed, 307 insertions(+), 213 deletions(-) create mode 100644 arch/x86/boot/compressed/efi_thunk_64.S Pulled, thanks Matt! Btw., I find the revert a bit sad: in most cases breaking virtualized environments isn't a regression really, it's _them_ who couple to the kernel in an incestuous way that causes the problem: fixes should come from them ... Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On 18 feb. 2015, at 13:43, Ingo Molnar mi...@kernel.org wrote: * Matt Fleming m...@codeblueprint.co.uk wrote: Folks, please pull the following fixes. The revert addresses a regression that Ard hit when booting Qemu and Xen, and the other patch ensures that we don't triple fault when receiving an NMI or MCE during an EFI mixed mode call, which may happen, for instance, when running perf. The pull is against tip/x86/efi because tip/x86/urgent doesn't contain commit d1a8d66b9177 (efi/libstub: Call get_memory_map() to obtain map and desc sizes) needed for the revert. If you'd prefer for me to resend this after the merge window closes, just let me know. The following changes since commit 3c01b74e818a7a3b2ee9b0d584cca0bc154a031c: Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/efi (2015-01-29 19:16: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 43a9f69692b232d1c64c913a27507eb14a1c47fd: Revert efi/libstub: Call get_memory_map() to obtain map and desc sizes (2015-02-18 11:38:13 +) * Leave a valid 64-bit IDT installed during runtime EFI mixed mode calls to avoid triple faults if an NMI/MCE is received. * Revert Ard's change to the libstub get_memory_map() that went into the v3.20 merge window because it causes boot regressions on Qemu and Xen. Matt Fleming (2): x86/efi: Avoid triple faults during EFI mixed mode calls Revert efi/libstub: Call get_memory_map() to obtain map and desc sizes arch/x86/boot/compressed/Makefile | 1 + arch/x86/boot/compressed/efi_stub_64.S | 25 arch/x86/boot/compressed/efi_thunk_64.S| 196 + arch/x86/platform/efi/efi_stub_64.S| 161 arch/x86/platform/efi/efi_thunk_64.S | 121 --- drivers/firmware/efi/libstub/efi-stub-helper.c | 16 +- 6 files changed, 307 insertions(+), 213 deletions(-) create mode 100644 arch/x86/boot/compressed/efi_thunk_64.S Pulled, thanks Matt! Btw., I find the revert a bit sad: in most cases breaking virtualized environments isn't a regression really, it's _them_ who couple to the kernel in an incestuous way that causes the problem: fixes should come from them ... It potentially breaks physical environments as well, it is just that i spotted it while testing virt ports of Tianocore. And frankly, the patch wasn't entirely correct to begin with Regards, Ard. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Sat, 2014-09-27 at 10:04 +0200, Valentin Rothberg wrote: > I will send some patches the > next weeks to show which bugs can be detected with the tool. Looking forward to those patches. If you do send them would you mind CC-ing me? Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Fri, Sep 26, 2014 at 2:34 PM, Matt Fleming wrote: > On Fri, 26 Sep, at 01:59:15PM, Paul Bolle wrote: >> >> I have a 800 line perl monster that checks for stuff like this. It's not >> very sophisticated but smart enough to spot typos like this one. I try >> to have it check each linux-next (and mainline) release. > > Very cool. > >> (I think Valentin Rothberg is trying to automate this properly. See >> http://www.linuxplumbersconf.org/2014/ocw/sessions/1863 .) > > Have either of you guys thought about asking for this to be included > with the 0-day kbuild bot or submitted under scripts/? > > It certainly seems like a useful bit of functionality. Yes, I was talking with Greg about including the tool in the 0-day testing. In addition, I am working on a patch to change the scripts/checkkconfigsymbols script (https://lkml.org/lkml/2014/9/22/336). The mayor difference between my tool and the script is that the script can only find bugs on a symbolic level (i.e., a reference on an feature that is not defined in Kconfig). The tool that I will present at the Plumbers Conference is additionally able to detect issue on the logic level, for instance an #ifdef block that can never be compiled as its precondition is contradictory. I will send some patches the next weeks to show which bugs can be detected with the tool. > Fengguang, the interesting bits of this thread start here, > > https://lkml.kernel.org/r/1411730854.7866.10.camel@x220 > > -- > Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Fri, Sep 26, 2014 at 2:34 PM, Matt Fleming m...@console-pimps.org wrote: On Fri, 26 Sep, at 01:59:15PM, Paul Bolle wrote: I have a 800 line perl monster that checks for stuff like this. It's not very sophisticated but smart enough to spot typos like this one. I try to have it check each linux-next (and mainline) release. Very cool. (I think Valentin Rothberg is trying to automate this properly. See http://www.linuxplumbersconf.org/2014/ocw/sessions/1863 .) Have either of you guys thought about asking for this to be included with the 0-day kbuild bot or submitted under scripts/? It certainly seems like a useful bit of functionality. Yes, I was talking with Greg about including the tool in the 0-day testing. In addition, I am working on a patch to change the scripts/checkkconfigsymbols script (https://lkml.org/lkml/2014/9/22/336). The mayor difference between my tool and the script is that the script can only find bugs on a symbolic level (i.e., a reference on an feature that is not defined in Kconfig). The tool that I will present at the Plumbers Conference is additionally able to detect issue on the logic level, for instance an #ifdef block that can never be compiled as its precondition is contradictory. I will send some patches the next weeks to show which bugs can be detected with the tool. Fengguang, the interesting bits of this thread start here, https://lkml.kernel.org/r/1411730854.7866.10.camel@x220 -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Sat, 2014-09-27 at 10:04 +0200, Valentin Rothberg wrote: I will send some patches the next weeks to show which bugs can be detected with the tool. Looking forward to those patches. If you do send them would you mind CC-ing me? Thanks, Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming wrote: > On Fri, 26 Sep, at 01:35:10PM, Ingo Molnar wrote: > > > > A delta fix would be nice at this point, I've got the x86 side > > tested and besides this build bug it's ready to go to Linus. > > Given that the typo doesn't result in an actual build failure, do you > still want the following delta fix? Ok, this one can indeed wait for the merge window - I'll send the other bits to Linus in a minute. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Fri, 2014-09-26 at 13:34 +0100, Matt Fleming wrote: > On Fri, 26 Sep, at 01:59:15PM, Paul Bolle wrote: > > > > I have a 800 line perl monster that checks for stuff like this. It's not > > very sophisticated but smart enough to spot typos like this one. I try > > to have it check each linux-next (and mainline) release. > > Very cool. Thanks. > > (I think Valentin Rothberg is trying to automate this properly. See > > http://www.linuxplumbersconf.org/2014/ocw/sessions/1863 .) > > Have either of you guys thought about asking for this to be included > with the 0-day kbuild bot or submitted under scripts/? > > It certainly seems like a useful bit of functionality. I've been testing things locally for three months now. People must have noticed an uptick in messages I send on this topic. (And, related, a decrease in the numbers of cleanup patches I send myself.) I've not been shouted at very often, so the signal to noise ratio is probably cool. This is about the third time I've written a monster like that. (I first started checking for Kconfig related defects in, I think, 2011.) About the only thing I'm happy with in this attempt is that it parses blobs separately. Ie, every release it checks for previously unseen blobs, parses those, and saves each blob level parse as a git note to that blob. Then it collects all relevant blob level notes, does the aggregate analysis and reports the issues it identifies. That report is saved away again as a note on the tag I'm checking. (I have not bothered to automate that last step.) The neat thing is, I think, that each release touches only a minority of files so parsing the tree is mostly a one time cost (encountered on the very first run). But, anyhow, I'm pretty sure Valentin is onto something much more sophisticated. > Fengguang, the interesting bits of this thread start here, > > https://lkml.kernel.org/r/1411730854.7866.10.camel@x220 Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Fri, 26 Sep, at 01:59:15PM, Paul Bolle wrote: > > I have a 800 line perl monster that checks for stuff like this. It's not > very sophisticated but smart enough to spot typos like this one. I try > to have it check each linux-next (and mainline) release. Very cool. > (I think Valentin Rothberg is trying to automate this properly. See > http://www.linuxplumbersconf.org/2014/ocw/sessions/1863 .) Have either of you guys thought about asking for this to be included with the 0-day kbuild bot or submitted under scripts/? It certainly seems like a useful bit of functionality. Fengguang, the interesting bits of this thread start here, https://lkml.kernel.org/r/1411730854.7866.10.camel@x220 -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Fri, 26 Sep, at 01:35:10PM, Ingo Molnar wrote:
>
> A delta fix would be nice at this point, I've got the x86 side
> tested and besides this build bug it's ready to go to Linus.
Given that the typo doesn't result in an actual build failure, do you
still want the following delta fix?
---
>From 7d4354dc767ba11d1555d27596a3dd3426eb3354 Mon Sep 17 00:00:00 2001
From: Matt Fleming
Date: Fri, 26 Sep 2014 13:11:05 +0100
Subject: [PATCH] efi: Fix CONFIG_EFI_ARMSTUB typo for building libstub
commit 84be880560fb ("Revert "efi/x86: efistub: Move shared dependencies
to "") introduced a typo into drivers/firmware/efi/Makefile
where CONFIG_EFI_ARM_STUB should instead be CONFIG_EFI_ARMSTUB.
The typo doesn't result in an actual build failure and was found with
Paul's "800 line perl monster" in linux-next.
The reason that we don't see a build failure is because arm64 (which is
now the only user of libstub) already includes logic to build libstub
from arch/arm64/Makefile.
Correct the typo anyway.
Reported-by: Paul Bolle
Signed-off-by: Matt Fleming
---
drivers/firmware/efi/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index aef6a95adef5..5b0d892a01c0 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -7,4 +7,4 @@ obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o
obj-$(CONFIG_UEFI_CPER)+= cper.o
obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o
obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o
-obj-$(CONFIG_EFI_ARM_STUB) += libstub/
+obj-$(CONFIG_EFI_ARMSTUB) += libstub/
--
1.9.3
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Fri, 2014-09-26 at 12:44 +0100, Matt Fleming wrote:
> On Fri, 26 Sep, at 01:27:34PM, Paul Bolle wrote:
> >
> > This Makefile was changed in the first patch. That became 84be880560fb
> > ("Revert "efi/x86: efistub: Move shared dependencies to ""),
> > which just landed in next-20140926.
> >
> > It appears to have introduced a typo, because:
> > CONFIG_EFI_ARM_STUB
> >
> > should probably have been:
> > CONFIG_EFI_ARMSTUB
>
> Crap. Thanks for catching that Paul. I'm wondering how this slipped
> through because that commit has an explicit Tested-by from Leif.
>
> Hell, even I built an arm64 EFI kernel before sending that commit.
>
> Ohh.. I see why no one caught this. From arch/arm64/Makefile,
>
> libs-$(CONFIG_EFI_STUB) += drivers/firmware/efi/libstub/
>
> so libstub will be built for arm64 regardless of the broken logic in
> drivers/firmware/efi/Makefile.
>
> Paul, how did you notice the typo? Did you hit an explicit build
> failure? It's definitely wrong and I'm trying to figure out whether I
> need to add some more testing to my build infrastructure to catch this
> kind of problem in the future.
I have a 800 line perl monster that checks for stuff like this. It's not
very sophisticated but smart enough to spot typos like this one. I try
to have it check each linux-next (and mainline) release.
(I think Valentin Rothberg is trying to automate this properly. See
http://www.linuxplumbersconf.org/2014/ocw/sessions/1863 .)
> The next question is: should we fix this up at this point in the merge
> cycle? It's basically just dead code.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Fri, 26 Sep, at 01:27:34PM, Paul Bolle wrote:
>
> This Makefile was changed in the first patch. That became 84be880560fb
> ("Revert "efi/x86: efistub: Move shared dependencies to ""),
> which just landed in next-20140926.
>
> It appears to have introduced a typo, because:
> CONFIG_EFI_ARM_STUB
>
> should probably have been:
> CONFIG_EFI_ARMSTUB
Crap. Thanks for catching that Paul. I'm wondering how this slipped
through because that commit has an explicit Tested-by from Leif.
Hell, even I built an arm64 EFI kernel before sending that commit.
Ohh.. I see why no one caught this. From arch/arm64/Makefile,
libs-$(CONFIG_EFI_STUB) += drivers/firmware/efi/libstub/
so libstub will be built for arm64 regardless of the broken logic in
drivers/firmware/efi/Makefile.
Paul, how did you notice the typo? Did you hit an explicit build
failure? It's definitely wrong and I'm trying to figure out whether I
need to add some more testing to my build infrastructure to catch this
kind of problem in the future.
The next question is: should we fix this up at this point in the merge
cycle? It's basically just dead code.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Paul Bolle wrote:
> On Thu, 2014-09-25 at 16:41 +0200, Ingo Molnar wrote:
> > * Matt Fleming wrote:
> >
> > > Folks,
> > >
> > > Please consider pulling the following fixes.
> > >
> > > The first two are releated to the bug report I got from Linus and Josh
> > > Boyer, whereby Fedora20 + grub2 systems were no longer booting. Linus
> > > reverted the offending commit that broke grub2 boot, but that left us in
> > > a state where Macbooks still didn't boot with EFI. This is fixed with
> > > the below revert and I'm dropping a noisey boot time efi_printk() based
> > > on Josh's request and Linus' OK.
> > >
> > > The third patch fixes a 32-bit EFI boot stub bug where garbled text is
> > > displayed on the screen if any of the efi_printk() statements run.
> > >
> > > The following changes since commit
> > > 3eddc69ffeba092d288c386646bfa5ec0fce25fd:
> > >
> > > x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8 (2014-09-14 15:24:31
> > > +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 115c6628a59044958c205f8468a1b3ba3d539e61:
> > >
> > > x86/efi: Truncate 64-bit values when calling 32-bit OutputString()
> > > (2014-09-24 21:56:46 +0100)
> > >
> > >
> > > * Revert the static library changes from the merge window since they're
> > >causing issues for Macbooks and Fedora + Grub2 - Matt Fleming
> > >
> > > * Delete the misleading "setup_efi_pci() failed!" message which some
> > >people are seeing when booting EFI - Matt Fleming
> > >
> > > * Fix printing strings from the 32-bit EFI boot stub by only passing
> > >32-bit addresses to the firmware - Matt Fleming
> > >
> > >
> > > Matt Fleming (3):
> > > Revert "efi/x86: efistub: Move shared dependencies to "
> > > x86/efi: Delete misleading efi_printk() error message
> > > x86/efi: Truncate 64-bit values when calling 32-bit OutputString()
> > >
> > > arch/x86/boot/compressed/Makefile | 3 +--
> > > arch/x86/boot/compressed/eboot.c | 44
> > > +++
> > > arch/x86/boot/compressed/eboot.h | 16 ++
> > > arch/x86/include/asm/efi.h| 24 -
> > > drivers/firmware/efi/Makefile | 2 +-
>
> This Makefile was changed in the first patch. That became 84be880560fb
> ("Revert "efi/x86: efistub: Move shared dependencies to ""),
> which just landed in next-20140926.
>
> It appears to have introduced a typo, because:
> CONFIG_EFI_ARM_STUB
>
> should probably have been:
> CONFIG_EFI_ARMSTUB
A delta fix would be nice at this point, I've got the x86 side
tested and besides this build bug it's ready to go to Linus.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Thu, 2014-09-25 at 16:41 +0200, Ingo Molnar wrote:
> * Matt Fleming wrote:
>
> > Folks,
> >
> > Please consider pulling the following fixes.
> >
> > The first two are releated to the bug report I got from Linus and Josh
> > Boyer, whereby Fedora20 + grub2 systems were no longer booting. Linus
> > reverted the offending commit that broke grub2 boot, but that left us in
> > a state where Macbooks still didn't boot with EFI. This is fixed with
> > the below revert and I'm dropping a noisey boot time efi_printk() based
> > on Josh's request and Linus' OK.
> >
> > The third patch fixes a 32-bit EFI boot stub bug where garbled text is
> > displayed on the screen if any of the efi_printk() statements run.
> >
> > The following changes since commit 3eddc69ffeba092d288c386646bfa5ec0fce25fd:
> >
> > x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8 (2014-09-14 15:24:31
> > +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 115c6628a59044958c205f8468a1b3ba3d539e61:
> >
> > x86/efi: Truncate 64-bit values when calling 32-bit OutputString()
> > (2014-09-24 21:56:46 +0100)
> >
> >
> > * Revert the static library changes from the merge window since they're
> >causing issues for Macbooks and Fedora + Grub2 - Matt Fleming
> >
> > * Delete the misleading "setup_efi_pci() failed!" message which some
> >people are seeing when booting EFI - Matt Fleming
> >
> > * Fix printing strings from the 32-bit EFI boot stub by only passing
> >32-bit addresses to the firmware - Matt Fleming
> >
> >
> > Matt Fleming (3):
> > Revert "efi/x86: efistub: Move shared dependencies to "
> > x86/efi: Delete misleading efi_printk() error message
> > x86/efi: Truncate 64-bit values when calling 32-bit OutputString()
> >
> > arch/x86/boot/compressed/Makefile | 3 +--
> > arch/x86/boot/compressed/eboot.c | 44
> > +++
> > arch/x86/boot/compressed/eboot.h | 16 ++
> > arch/x86/include/asm/efi.h| 24 -
> > drivers/firmware/efi/Makefile | 2 +-
This Makefile was changed in the first patch. That became 84be880560fb
("Revert "efi/x86: efistub: Move shared dependencies to ""),
which just landed in next-20140926.
It appears to have introduced a typo, because:
CONFIG_EFI_ARM_STUB
should probably have been:
CONFIG_EFI_ARMSTUB
> > 5 files changed, 44 insertions(+), 45 deletions(-)
> >
> > --
> > Matt Fleming, Intel Open Source Technology Center
>
> Pulled, thanks Matt!
>
> I'll give it some testing and then send it to Linus with other
> x86 fixes.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Thu, 2014-09-25 at 16:41 +0200, Ingo Molnar wrote: * Matt Fleming m...@console-pimps.org wrote: Folks, Please consider pulling the following fixes. The first two are releated to the bug report I got from Linus and Josh Boyer, whereby Fedora20 + grub2 systems were no longer booting. Linus reverted the offending commit that broke grub2 boot, but that left us in a state where Macbooks still didn't boot with EFI. This is fixed with the below revert and I'm dropping a noisey boot time efi_printk() based on Josh's request and Linus' OK. The third patch fixes a 32-bit EFI boot stub bug where garbled text is displayed on the screen if any of the efi_printk() statements run. The following changes since commit 3eddc69ffeba092d288c386646bfa5ec0fce25fd: x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8 (2014-09-14 15:24:31 +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 115c6628a59044958c205f8468a1b3ba3d539e61: x86/efi: Truncate 64-bit values when calling 32-bit OutputString() (2014-09-24 21:56:46 +0100) * Revert the static library changes from the merge window since they're causing issues for Macbooks and Fedora + Grub2 - Matt Fleming * Delete the misleading setup_efi_pci() failed! message which some people are seeing when booting EFI - Matt Fleming * Fix printing strings from the 32-bit EFI boot stub by only passing 32-bit addresses to the firmware - Matt Fleming Matt Fleming (3): Revert efi/x86: efistub: Move shared dependencies to asm/efi.h x86/efi: Delete misleading efi_printk() error message x86/efi: Truncate 64-bit values when calling 32-bit OutputString() arch/x86/boot/compressed/Makefile | 3 +-- arch/x86/boot/compressed/eboot.c | 44 +++ arch/x86/boot/compressed/eboot.h | 16 ++ arch/x86/include/asm/efi.h| 24 - drivers/firmware/efi/Makefile | 2 +- This Makefile was changed in the first patch. That became 84be880560fb (Revert efi/x86: efistub: Move shared dependencies to asm/efi.h), which just landed in next-20140926. It appears to have introduced a typo, because: CONFIG_EFI_ARM_STUB should probably have been: CONFIG_EFI_ARMSTUB 5 files changed, 44 insertions(+), 45 deletions(-) -- Matt Fleming, Intel Open Source Technology Center Pulled, thanks Matt! I'll give it some testing and then send it to Linus with other x86 fixes. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Paul Bolle pebo...@tiscali.nl wrote: On Thu, 2014-09-25 at 16:41 +0200, Ingo Molnar wrote: * Matt Fleming m...@console-pimps.org wrote: Folks, Please consider pulling the following fixes. The first two are releated to the bug report I got from Linus and Josh Boyer, whereby Fedora20 + grub2 systems were no longer booting. Linus reverted the offending commit that broke grub2 boot, but that left us in a state where Macbooks still didn't boot with EFI. This is fixed with the below revert and I'm dropping a noisey boot time efi_printk() based on Josh's request and Linus' OK. The third patch fixes a 32-bit EFI boot stub bug where garbled text is displayed on the screen if any of the efi_printk() statements run. The following changes since commit 3eddc69ffeba092d288c386646bfa5ec0fce25fd: x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8 (2014-09-14 15:24:31 +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 115c6628a59044958c205f8468a1b3ba3d539e61: x86/efi: Truncate 64-bit values when calling 32-bit OutputString() (2014-09-24 21:56:46 +0100) * Revert the static library changes from the merge window since they're causing issues for Macbooks and Fedora + Grub2 - Matt Fleming * Delete the misleading setup_efi_pci() failed! message which some people are seeing when booting EFI - Matt Fleming * Fix printing strings from the 32-bit EFI boot stub by only passing 32-bit addresses to the firmware - Matt Fleming Matt Fleming (3): Revert efi/x86: efistub: Move shared dependencies to asm/efi.h x86/efi: Delete misleading efi_printk() error message x86/efi: Truncate 64-bit values when calling 32-bit OutputString() arch/x86/boot/compressed/Makefile | 3 +-- arch/x86/boot/compressed/eboot.c | 44 +++ arch/x86/boot/compressed/eboot.h | 16 ++ arch/x86/include/asm/efi.h| 24 - drivers/firmware/efi/Makefile | 2 +- This Makefile was changed in the first patch. That became 84be880560fb (Revert efi/x86: efistub: Move shared dependencies to asm/efi.h), which just landed in next-20140926. It appears to have introduced a typo, because: CONFIG_EFI_ARM_STUB should probably have been: CONFIG_EFI_ARMSTUB A delta fix would be nice at this point, I've got the x86 side tested and besides this build bug it's ready to go to Linus. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Fri, 26 Sep, at 01:27:34PM, Paul Bolle wrote: This Makefile was changed in the first patch. That became 84be880560fb (Revert efi/x86: efistub: Move shared dependencies to asm/efi.h), which just landed in next-20140926. It appears to have introduced a typo, because: CONFIG_EFI_ARM_STUB should probably have been: CONFIG_EFI_ARMSTUB Crap. Thanks for catching that Paul. I'm wondering how this slipped through because that commit has an explicit Tested-by from Leif. Hell, even I built an arm64 EFI kernel before sending that commit. Ohh.. I see why no one caught this. From arch/arm64/Makefile, libs-$(CONFIG_EFI_STUB) += drivers/firmware/efi/libstub/ so libstub will be built for arm64 regardless of the broken logic in drivers/firmware/efi/Makefile. Paul, how did you notice the typo? Did you hit an explicit build failure? It's definitely wrong and I'm trying to figure out whether I need to add some more testing to my build infrastructure to catch this kind of problem in the future. The next question is: should we fix this up at this point in the merge cycle? It's basically just dead code. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Fri, 2014-09-26 at 12:44 +0100, Matt Fleming wrote: On Fri, 26 Sep, at 01:27:34PM, Paul Bolle wrote: This Makefile was changed in the first patch. That became 84be880560fb (Revert efi/x86: efistub: Move shared dependencies to asm/efi.h), which just landed in next-20140926. It appears to have introduced a typo, because: CONFIG_EFI_ARM_STUB should probably have been: CONFIG_EFI_ARMSTUB Crap. Thanks for catching that Paul. I'm wondering how this slipped through because that commit has an explicit Tested-by from Leif. Hell, even I built an arm64 EFI kernel before sending that commit. Ohh.. I see why no one caught this. From arch/arm64/Makefile, libs-$(CONFIG_EFI_STUB) += drivers/firmware/efi/libstub/ so libstub will be built for arm64 regardless of the broken logic in drivers/firmware/efi/Makefile. Paul, how did you notice the typo? Did you hit an explicit build failure? It's definitely wrong and I'm trying to figure out whether I need to add some more testing to my build infrastructure to catch this kind of problem in the future. I have a 800 line perl monster that checks for stuff like this. It's not very sophisticated but smart enough to spot typos like this one. I try to have it check each linux-next (and mainline) release. (I think Valentin Rothberg is trying to automate this properly. See http://www.linuxplumbersconf.org/2014/ocw/sessions/1863 .) The next question is: should we fix this up at this point in the merge cycle? It's basically just dead code. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Fri, 26 Sep, at 01:35:10PM, Ingo Molnar wrote: A delta fix would be nice at this point, I've got the x86 side tested and besides this build bug it's ready to go to Linus. Given that the typo doesn't result in an actual build failure, do you still want the following delta fix? --- From 7d4354dc767ba11d1555d27596a3dd3426eb3354 Mon Sep 17 00:00:00 2001 From: Matt Fleming matt.flem...@intel.com Date: Fri, 26 Sep 2014 13:11:05 +0100 Subject: [PATCH] efi: Fix CONFIG_EFI_ARMSTUB typo for building libstub commit 84be880560fb (Revert efi/x86: efistub: Move shared dependencies to asm/efi.h) introduced a typo into drivers/firmware/efi/Makefile where CONFIG_EFI_ARM_STUB should instead be CONFIG_EFI_ARMSTUB. The typo doesn't result in an actual build failure and was found with Paul's 800 line perl monster in linux-next. The reason that we don't see a build failure is because arm64 (which is now the only user of libstub) already includes logic to build libstub from arch/arm64/Makefile. Correct the typo anyway. Reported-by: Paul Bolle pebo...@tiscali.nl Signed-off-by: Matt Fleming matt.flem...@intel.com --- drivers/firmware/efi/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile index aef6a95adef5..5b0d892a01c0 100644 --- a/drivers/firmware/efi/Makefile +++ b/drivers/firmware/efi/Makefile @@ -7,4 +7,4 @@ obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o obj-$(CONFIG_UEFI_CPER)+= cper.o obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o -obj-$(CONFIG_EFI_ARM_STUB) += libstub/ +obj-$(CONFIG_EFI_ARMSTUB) += libstub/ -- 1.9.3 -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Fri, 26 Sep, at 01:59:15PM, Paul Bolle wrote: I have a 800 line perl monster that checks for stuff like this. It's not very sophisticated but smart enough to spot typos like this one. I try to have it check each linux-next (and mainline) release. Very cool. (I think Valentin Rothberg is trying to automate this properly. See http://www.linuxplumbersconf.org/2014/ocw/sessions/1863 .) Have either of you guys thought about asking for this to be included with the 0-day kbuild bot or submitted under scripts/? It certainly seems like a useful bit of functionality. Fengguang, the interesting bits of this thread start here, https://lkml.kernel.org/r/1411730854.7866.10.camel@x220 -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Fri, 2014-09-26 at 13:34 +0100, Matt Fleming wrote: On Fri, 26 Sep, at 01:59:15PM, Paul Bolle wrote: I have a 800 line perl monster that checks for stuff like this. It's not very sophisticated but smart enough to spot typos like this one. I try to have it check each linux-next (and mainline) release. Very cool. Thanks. (I think Valentin Rothberg is trying to automate this properly. See http://www.linuxplumbersconf.org/2014/ocw/sessions/1863 .) Have either of you guys thought about asking for this to be included with the 0-day kbuild bot or submitted under scripts/? It certainly seems like a useful bit of functionality. I've been testing things locally for three months now. People must have noticed an uptick in messages I send on this topic. (And, related, a decrease in the numbers of cleanup patches I send myself.) I've not been shouted at very often, so the signal to noise ratio is probably cool. This is about the third time I've written a monster like that. (I first started checking for Kconfig related defects in, I think, 2011.) About the only thing I'm happy with in this attempt is that it parses blobs separately. Ie, every release it checks for previously unseen blobs, parses those, and saves each blob level parse as a git note to that blob. Then it collects all relevant blob level notes, does the aggregate analysis and reports the issues it identifies. That report is saved away again as a note on the tag I'm checking. (I have not bothered to automate that last step.) The neat thing is, I think, that each release touches only a minority of files so parsing the tree is mostly a one time cost (encountered on the very first run). But, anyhow, I'm pretty sure Valentin is onto something much more sophisticated. Fengguang, the interesting bits of this thread start here, https://lkml.kernel.org/r/1411730854.7866.10.camel@x220 Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming m...@console-pimps.org wrote: On Fri, 26 Sep, at 01:35:10PM, Ingo Molnar wrote: A delta fix would be nice at this point, I've got the x86 side tested and besides this build bug it's ready to go to Linus. Given that the typo doesn't result in an actual build failure, do you still want the following delta fix? Ok, this one can indeed wait for the merge window - I'll send the other bits to Linus in a minute. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Thu, 25 Sep, at 04:41:27PM, Ingo Molnar wrote: > > Pulled, thanks Matt! > > I'll give it some testing and then send it to Linus with other > x86 fixes. Thanks! I noticed that the 0day bot isn't working properly at the moment (at least for me), so additional testing is most welcome. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming wrote: > Folks, > > Please consider pulling the following fixes. > > The first two are releated to the bug report I got from Linus and Josh > Boyer, whereby Fedora20 + grub2 systems were no longer booting. Linus > reverted the offending commit that broke grub2 boot, but that left us in > a state where Macbooks still didn't boot with EFI. This is fixed with > the below revert and I'm dropping a noisey boot time efi_printk() based > on Josh's request and Linus' OK. > > The third patch fixes a 32-bit EFI boot stub bug where garbled text is > displayed on the screen if any of the efi_printk() statements run. > > The following changes since commit 3eddc69ffeba092d288c386646bfa5ec0fce25fd: > > x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8 (2014-09-14 15:24:31 > +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 115c6628a59044958c205f8468a1b3ba3d539e61: > > x86/efi: Truncate 64-bit values when calling 32-bit OutputString() > (2014-09-24 21:56:46 +0100) > > > * Revert the static library changes from the merge window since they're >causing issues for Macbooks and Fedora + Grub2 - Matt Fleming > > * Delete the misleading "setup_efi_pci() failed!" message which some >people are seeing when booting EFI - Matt Fleming > > * Fix printing strings from the 32-bit EFI boot stub by only passing >32-bit addresses to the firmware - Matt Fleming > > > Matt Fleming (3): > Revert "efi/x86: efistub: Move shared dependencies to " > x86/efi: Delete misleading efi_printk() error message > x86/efi: Truncate 64-bit values when calling 32-bit OutputString() > > arch/x86/boot/compressed/Makefile | 3 +-- > arch/x86/boot/compressed/eboot.c | 44 > +++ > arch/x86/boot/compressed/eboot.h | 16 ++ > arch/x86/include/asm/efi.h| 24 - > drivers/firmware/efi/Makefile | 2 +- > 5 files changed, 44 insertions(+), 45 deletions(-) > > -- > Matt Fleming, Intel Open Source Technology Center Pulled, thanks Matt! I'll give it some testing and then send it to Linus with other x86 fixes. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming m...@console-pimps.org wrote: Folks, Please consider pulling the following fixes. The first two are releated to the bug report I got from Linus and Josh Boyer, whereby Fedora20 + grub2 systems were no longer booting. Linus reverted the offending commit that broke grub2 boot, but that left us in a state where Macbooks still didn't boot with EFI. This is fixed with the below revert and I'm dropping a noisey boot time efi_printk() based on Josh's request and Linus' OK. The third patch fixes a 32-bit EFI boot stub bug where garbled text is displayed on the screen if any of the efi_printk() statements run. The following changes since commit 3eddc69ffeba092d288c386646bfa5ec0fce25fd: x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8 (2014-09-14 15:24:31 +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 115c6628a59044958c205f8468a1b3ba3d539e61: x86/efi: Truncate 64-bit values when calling 32-bit OutputString() (2014-09-24 21:56:46 +0100) * Revert the static library changes from the merge window since they're causing issues for Macbooks and Fedora + Grub2 - Matt Fleming * Delete the misleading setup_efi_pci() failed! message which some people are seeing when booting EFI - Matt Fleming * Fix printing strings from the 32-bit EFI boot stub by only passing 32-bit addresses to the firmware - Matt Fleming Matt Fleming (3): Revert efi/x86: efistub: Move shared dependencies to asm/efi.h x86/efi: Delete misleading efi_printk() error message x86/efi: Truncate 64-bit values when calling 32-bit OutputString() arch/x86/boot/compressed/Makefile | 3 +-- arch/x86/boot/compressed/eboot.c | 44 +++ arch/x86/boot/compressed/eboot.h | 16 ++ arch/x86/include/asm/efi.h| 24 - drivers/firmware/efi/Makefile | 2 +- 5 files changed, 44 insertions(+), 45 deletions(-) -- Matt Fleming, Intel Open Source Technology Center Pulled, thanks Matt! I'll give it some testing and then send it to Linus with other x86 fixes. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Thu, 25 Sep, at 04:41:27PM, Ingo Molnar wrote: Pulled, thanks Matt! I'll give it some testing and then send it to Linus with other x86 fixes. Thanks! I noticed that the 0day bot isn't working properly at the moment (at least for me), so additional testing is most welcome. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming wrote: > On Tue, 09 Sep, at 07:07:49AM, Ingo Molnar wrote: > > > > So please only put the 3 regression fixes into efi-urgent, the > > rest can go into the v3.18 pile. > > OK, I'll sort that out. Thanks! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Tue, 09 Sep, at 07:07:49AM, Ingo Molnar wrote: > > So please only put the 3 regression fixes into efi-urgent, the > rest can go into the v3.18 pile. OK, I'll sort that out. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
On Tue, 09 Sep, at 07:07:49AM, Ingo Molnar wrote: So please only put the 3 regression fixes into efi-urgent, the rest can go into the v3.18 pile. OK, I'll sort that out. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming m...@console-pimps.org wrote: On Tue, 09 Sep, at 07:07:49AM, Ingo Molnar wrote: So please only put the 3 regression fixes into efi-urgent, the rest can go into the v3.18 pile. OK, I'll sort that out. Thanks! Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming wrote: > Folks, > > Please queue up the following fixes, mainly for regressions introduced > in the merge window or -rc2. So the rule for post-rc1 merges is to fix regressions 'only', not 'mainly'! > > Mark Rustad (1): > efi: Resolve some shadow warnings That's not a critical regression. > > Mark Salter (1): > efi/arm64: Fix fdt-related memory reservation That's a regression fix. > Mathias Krause (4): > x86/efi: Remove unused efi_call* macros > x86/efi: Unexport add_efi_memmap variable > x86/efi: Update comment regarding required phys mapped EFI services > x86/efi: Mark initialization code as such Neither of these 4 changes is a critical regression! > Matt Fleming (1): > x86/efi: Fixup GOT in all boot code paths That's a regression fix. > Yinghai Lu (1): > x86/efi: Only load initrd above 4g on second try This revert is a regression fix too. So please only put the 3 regression fixes into efi-urgent, the rest can go into the v3.18 pile. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming m...@console-pimps.org wrote: Folks, Please queue up the following fixes, mainly for regressions introduced in the merge window or -rc2. So the rule for post-rc1 merges is to fix regressions 'only', not 'mainly'! Mark Rustad (1): efi: Resolve some shadow warnings That's not a critical regression. Mark Salter (1): efi/arm64: Fix fdt-related memory reservation That's a regression fix. Mathias Krause (4): x86/efi: Remove unused efi_call* macros x86/efi: Unexport add_efi_memmap variable x86/efi: Update comment regarding required phys mapped EFI services x86/efi: Mark initialization code as such Neither of these 4 changes is a critical regression! Matt Fleming (1): x86/efi: Fixup GOT in all boot code paths That's a regression fix. Yinghai Lu (1): x86/efi: Only load initrd above 4g on second try This revert is a regression fix too. So please only put the 3 regression fixes into efi-urgent, the rest can go into the v3.18 pile. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming wrote: > Hi guys, please pull the following fixes, which trade the locking > WARN_ON()s in the efivars code for the more usual lockdep_*() functions > and an arm64 EFI change that allows the gamut of runtime services to be > invoked. > > The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: > > Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) > > 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 6a7519e81321343165f89abb8b616df186d3e57a: > > efi/arm64: Store Runtime Services revision (2014-08-22 08:45:41 +0100) > > > * WARN_ON(!spin_is_locked()) always triggers on non-SMP machines. >Swap it for the more canonical lockdep_assert_held() which always >does the right thing - Guenter Roeck > > * Assign the correct value to efi.runtime_version on arm64 so that all >the runtime services can be invoked - Semen Protsenko > > > Guenter Roeck (1): > firmware: Do not use WARN_ON(!spin_is_locked()) > > Semen Protsenko (1): > efi/arm64: Store Runtime Services revision > > arch/arm64/kernel/efi.c | 2 ++ > drivers/firmware/efi/vars.c | 8 > 2 files changed, 6 insertions(+), 4 deletions(-) Pulled into tip:x86/urgent, thanks Matt! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming m...@console-pimps.org wrote: Hi guys, please pull the following fixes, which trade the locking WARN_ON()s in the efivars code for the more usual lockdep_*() functions and an arm64 EFI change that allows the gamut of runtime services to be invoked. The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) 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 6a7519e81321343165f89abb8b616df186d3e57a: efi/arm64: Store Runtime Services revision (2014-08-22 08:45:41 +0100) * WARN_ON(!spin_is_locked()) always triggers on non-SMP machines. Swap it for the more canonical lockdep_assert_held() which always does the right thing - Guenter Roeck * Assign the correct value to efi.runtime_version on arm64 so that all the runtime services can be invoked - Semen Protsenko Guenter Roeck (1): firmware: Do not use WARN_ON(!spin_is_locked()) Semen Protsenko (1): efi/arm64: Store Runtime Services revision arch/arm64/kernel/efi.c | 2 ++ drivers/firmware/efi/vars.c | 8 2 files changed, 6 insertions(+), 4 deletions(-) Pulled into tip:x86/urgent, thanks Matt! Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming wrote:
> Guys, please pull the following. One of the fixes is for a regression
> introduced during the merge window. The other two are bugs that have
> existed in the EFI boot stub for a while, but which have only just been
> reported.
>
> I'm going to take care of submitting the later two to stable separately
> because they won't apply cleanly as-is.
>
> The following changes since commit 204b0a1a4b92612c957a042df1a3be0e9cc79391:
>
> x86, efi: Abstract x86 efi_early calls (2014-03-26 11:30:03 -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 47514c996fac5e6f13ef3a4c5e23f1c5cffabb7b:
>
> efi: Pass correct file handle to efi_file_{read,close} (2014-04-10 21:20:03
> +0100)
>
>
> * Fix EFI boot regression introduced during the merge window where the
>firmware was reading random values from the stack because we were
>passing a pointer to the wrong object type.
>
> * Kernel corruption has been reported when booting with the EFI boot
>stub which was tracked down to setting a bogus value for
>bp->hdr.code32_start, resulting in corruption during relocation.
>
> * Olivier Martin reported that the wrong file handles were being passed
>to efi_file_(read|close), which works for x86 by luck due to the way
>that the FAT driver is implemented, but doesn't work on ARM.
>
>
> Matt Fleming (3):
> x86/efi: Fix boot failure with EFI stub
> x86/efi: Correct EFI boot stub use of code32_start
> efi: Pass correct file handle to efi_file_{read,close}
>
> arch/x86/boot/compressed/eboot.c | 19 ++-
> arch/x86/boot/compressed/head_32.S | 8 ++--
> arch/x86/boot/compressed/head_64.S | 9 +++--
> drivers/firmware/efi/efi-stub-helper.c | 6 +++---
> 4 files changed, 18 insertions(+), 24 deletions(-)
Pulled, thanks a lot Matt!
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] EFI urgent fixes
* Matt Fleming m...@console-pimps.org wrote:
Guys, please pull the following. One of the fixes is for a regression
introduced during the merge window. The other two are bugs that have
existed in the EFI boot stub for a while, but which have only just been
reported.
I'm going to take care of submitting the later two to stable separately
because they won't apply cleanly as-is.
The following changes since commit 204b0a1a4b92612c957a042df1a3be0e9cc79391:
x86, efi: Abstract x86 efi_early calls (2014-03-26 11:30:03 -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 47514c996fac5e6f13ef3a4c5e23f1c5cffabb7b:
efi: Pass correct file handle to efi_file_{read,close} (2014-04-10 21:20:03
+0100)
* Fix EFI boot regression introduced during the merge window where the
firmware was reading random values from the stack because we were
passing a pointer to the wrong object type.
* Kernel corruption has been reported when booting with the EFI boot
stub which was tracked down to setting a bogus value for
bp-hdr.code32_start, resulting in corruption during relocation.
* Olivier Martin reported that the wrong file handles were being passed
to efi_file_(read|close), which works for x86 by luck due to the way
that the FAT driver is implemented, but doesn't work on ARM.
Matt Fleming (3):
x86/efi: Fix boot failure with EFI stub
x86/efi: Correct EFI boot stub use of code32_start
efi: Pass correct file handle to efi_file_{read,close}
arch/x86/boot/compressed/eboot.c | 19 ++-
arch/x86/boot/compressed/head_32.S | 8 ++--
arch/x86/boot/compressed/head_64.S | 9 +++--
drivers/firmware/efi/efi-stub-helper.c | 6 +++---
4 files changed, 18 insertions(+), 24 deletions(-)
Pulled, thanks a lot Matt!
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
