From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org,
Bryan ODonoghue <bryan.odonoghue.lkml@nexus-software.ie>,
Tom Zanussi <tom.zanussi@intel.com>,
Darren Hart <dvhart@linux.intel.com>,
Josh Triplett <josh@joshtriplett.org>,
Matthew Garrett <mjg59@srcf.ucam.org>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Josh Boyer <jwboyer@redhat.com>,
Matt Fleming <matt.fleming@intel.com>
Subject: [ 02/13] x86, efi: Dont map Boot Services on i386
Date: Wed, 2 Oct 2013 21:04:27 -0700 [thread overview]
Message-ID: <20131003040400.921984711@linuxfoundation.org> (raw)
In-Reply-To: <20131003040400.753642257@linuxfoundation.org>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josh Boyer <jwboyer@redhat.com>
commit 700870119f49084da004ab588ea2b799689efaf7 upstream.
Add patch to fix 32bit EFI service mapping (rhbz 726701)
Multiple people are reporting hitting the following WARNING on i386,
WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440()
Modules linked in:
Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95
Call Trace:
[<c102b6af>] warn_slowpath_common+0x5f/0x80
[<c1023fb3>] ? __ioremap_caller+0x3d3/0x440
[<c1023fb3>] ? __ioremap_caller+0x3d3/0x440
[<c102b6ed>] warn_slowpath_null+0x1d/0x20
[<c1023fb3>] __ioremap_caller+0x3d3/0x440
[<c106007b>] ? get_usage_chars+0xfb/0x110
[<c102d937>] ? vprintk_emit+0x147/0x480
[<c1418593>] ? efi_enter_virtual_mode+0x1e4/0x3de
[<c102406a>] ioremap_cache+0x1a/0x20
[<c1418593>] ? efi_enter_virtual_mode+0x1e4/0x3de
[<c1418593>] efi_enter_virtual_mode+0x1e4/0x3de
[<c1407984>] start_kernel+0x286/0x2f4
[<c1407535>] ? repair_env_string+0x51/0x51
[<c1407362>] i386_start_kernel+0x12c/0x12f
Due to the workaround described in commit 916f676f8 ("x86, efi: Retain
boot service code until after switching to virtual mode") EFI Boot
Service regions are mapped for a period during boot. Unfortunately, with
the limited size of the i386 direct kernel map it's possible that some
of the Boot Service regions will not be directly accessible, which
causes them to be ioremap()'d, triggering the above warning as the
regions are marked as E820_RAM in the e820 memmap.
There are currently only two situations where we need to map EFI Boot
Service regions,
1. To workaround the firmware bug described in 916f676f8
2. To access the ACPI BGRT image
but since we haven't seen an i386 implementation that requires either,
this simple fix should suffice for now.
[ Added to changelog - Matt ]
Reported-by: Bryan O'Donoghue <bryan.odonoghue.lkml@nexus-software.ie>
Acked-by: Tom Zanussi <tom.zanussi@intel.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/platform/efi/efi.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -588,10 +588,13 @@ void __init efi_enter_virtual_mode(void)
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
- if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
- md->type != EFI_BOOT_SERVICES_CODE &&
- md->type != EFI_BOOT_SERVICES_DATA)
- continue;
+ if (!(md->attribute & EFI_MEMORY_RUNTIME)) {
+#ifdef CONFIG_X86_64
+ if (md->type != EFI_BOOT_SERVICES_CODE &&
+ md->type != EFI_BOOT_SERVICES_DATA)
+#endif
+ continue;
+ }
size = md->num_pages << EFI_PAGE_SHIFT;
end = md->phys_addr + size;
next prev parent reply other threads:[~2013-10-03 4:04 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-03 4:04 [ 00/13] 3.0.99-stable review Greg Kroah-Hartman
2013-10-03 4:04 ` [ 01/13] x86/reboot: Add quirk to make Dell C6100 use reboot=pci automatically Greg Kroah-Hartman
2013-10-03 4:04 ` Greg Kroah-Hartman [this message]
2013-10-03 4:04 ` [ 03/13] staging: vt6656: [BUG] main_usb.c oops on device_close move flag earlier Greg Kroah-Hartman
2013-10-03 4:04 ` [ 04/13] xhci: Fix oops happening after address device timeout Greg Kroah-Hartman
2013-10-03 4:04 ` [ 05/13] xhci: Fix race between ep halt and URB cancellation Greg Kroah-Hartman
2013-10-03 4:04 ` [ 06/13] usb/core/devio.c: Dont reject control message to endpoint with wrong direction bit Greg Kroah-Hartman
2013-10-03 4:04 ` [ 07/13] dm snapshot: workaround for a false positive lockdep warning Greg Kroah-Hartman
2013-10-03 4:04 ` [ 08/13] dm-snapshot: fix performance degradation due to small hash size Greg Kroah-Hartman
2013-10-03 4:04 ` [ 09/13] drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER Greg Kroah-Hartman
2013-10-03 4:04 ` [ 10/13] hwmon: (applesmc) Check key count before proceeding Greg Kroah-Hartman
2013-10-03 4:04 ` [ 11/13] mm: fix aio performance regression for database caused by THP Greg Kroah-Hartman
2013-10-03 4:04 ` [ 12/13] hwmon: (applesmc) Silence uninitialized warnings Greg Kroah-Hartman
2013-10-03 4:04 ` [ 13/13] splice: fix racy pipe->buffers uses Greg Kroah-Hartman
2013-10-03 5:53 ` [ 00/13] 3.0.99-stable review Guenter Roeck
2013-10-03 12:47 ` Christoph Biedl
2013-10-03 13:29 ` Guenter Roeck
2013-10-03 13:35 ` Khalid Aziz
2013-10-03 14:41 ` Christoph Biedl
2013-10-03 14:56 ` Khalid Aziz
2013-10-03 15:12 ` Khalid Aziz
2013-10-03 18:34 ` Greg Kroah-Hartman
2013-10-03 19:15 ` Christoph Biedl
2013-10-03 20:03 ` Khalid Aziz
2013-10-03 15:56 ` Guenter Roeck
2013-10-03 18:40 ` Greg Kroah-Hartman
2013-10-03 21:18 ` Guenter Roeck
2013-10-03 18:36 ` Greg Kroah-Hartman
2013-10-04 0:16 ` Shuah Khan
2013-10-04 2:37 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131003040400.921984711@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=bryan.odonoghue.lkml@nexus-software.ie \
--cc=dvhart@linux.intel.com \
--cc=hpa@zytor.com \
--cc=josh@joshtriplett.org \
--cc=jwboyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=mingo@kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tom.zanussi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).