From: Lianbo Jiang <lijiang@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org,
x86@kernel.org, ardb@kernel.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dvhart@infradead.org,
andy@infradead.org, hpa@zytor.com, kexec@lists.infradead.org,
bhe@redhat.com, dyoung@redhat.com
Subject: [PATCH] x86/efi: Do not release sub-1MB memory regions when the crashkernel option is specified
Date: Wed, 7 Apr 2021 22:03:16 +0800 [thread overview]
Message-ID: <20210407140316.30210-1-lijiang@redhat.com> (raw)
Some sub-1MB memory regions may be reserved by EFI boot services, and the
memory regions will be released later in the efi_free_boot_services().
Currently, always reserve all sub-1MB memory regions when the crashkernel
option is specified, but unfortunately EFI boot services may have already
reserved some sub-1MB memory regions before the crash_reserve_low_1M() is
called, which makes that the crash_reserve_low_1M() only own the
remaining sub-1MB memory regions, not all sub-1MB memory regions, because,
subsequently EFI boot services will free its own sub-1MB memory regions.
Eventually, DMA will be able to allocate memory from the sub-1MB area and
cause the following error:
crash> kmem -s |grep invalid
kmem: dma-kmalloc-512: slab: ffffd52c40001900 invalid freepointer: ffff9403c0067300
kmem: dma-kmalloc-512: slab: ffffd52c40001900 invalid freepointer: ffff9403c0067300
crash> vtop ffff9403c0067300
VIRTUAL PHYSICAL
ffff9403c0067300 67300 --->The physical address falls into this range [0x0000000000063000-0x000000000008efff]
kernel debugging log:
...
[ 0.008927] memblock_reserve: [0x0000000000010000-0x0000000000013fff] efi_reserve_boot_services+0x85/0xd0
[ 0.008930] memblock_reserve: [0x0000000000063000-0x000000000008efff] efi_reserve_boot_services+0x85/0xd0
...
[ 0.009425] memblock_reserve: [0x0000000000000000-0x00000000000fffff] crash_reserve_low_1M+0x2c/0x49
...
[ 0.010586] Zone ranges:
[ 0.010587] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.010589] DMA32 [mem 0x0000000001000000-0x00000000ffffffff]
[ 0.010591] Normal [mem 0x0000000100000000-0x0000000c7fffffff]
[ 0.010593] Device empty
...
[ 8.814894] __memblock_free_late: [0x0000000000063000-0x000000000008efff] efi_free_boot_services+0x14b/0x23b
[ 8.815793] __memblock_free_late: [0x0000000000010000-0x0000000000013fff] efi_free_boot_services+0x14b/0x23b
Do not release sub-1MB memory regions even though they are reserved by
EFI boot services, so that always reserve all sub-1MB memory regions when
the crashkernel option is specified.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
arch/x86/platform/efi/quirks.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 67d93a243c35..637f932c4fd4 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -18,6 +18,7 @@
#include <asm/cpu_device_id.h>
#include <asm/realmode.h>
#include <asm/reboot.h>
+#include <asm/cmdline.h>
#define EFI_MIN_RESERVE 5120
@@ -303,6 +304,19 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
*/
static __init bool can_free_region(u64 start, u64 size)
{
+ /*
+ * Some sub-1MB memory regions may be reserved by EFI boot
+ * services, and these memory regions will be released later
+ * in the efi_free_boot_services().
+ *
+ * Do not release sub-1MB memory regions even though they are
+ * reserved by EFI boot services, because, always reserve all
+ * sub-1MB memory when the crashkernel option is specified.
+ */
+ if (cmdline_find_option(boot_command_line, "crashkernel", NULL, 0) > 0
+ && (start + size < (1<<20)))
+ return false;
+
if (start + size > __pa_symbol(_text) && start <= __pa_symbol(_end))
return false;
--
2.17.1
next reply other threads:[~2021-04-07 14:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-07 14:03 Lianbo Jiang [this message]
2021-04-09 12:44 ` [PATCH] x86/efi: Do not release sub-1MB memory regions when the crashkernel option is specified Baoquan He
2021-04-10 2:56 ` lijiang
[not found] ` <D7D32C89-4F99-434A-B7AF-7BEBDA494172@zytor.com>
2021-04-12 1:13 ` Baoquan He
2021-04-12 1:49 ` Andy Lutomirski
2021-04-12 9:52 ` Baoquan He
2021-04-12 10:49 ` lijiang
2021-04-12 15:24 ` Andy Lutomirski
2021-04-13 9:45 ` Baoquan He
[not found] ` <CANU+ZydgWTSg+iUix8ggn-cSPpg8qtShaUQ47cOeeMxFmXp_zQ@mail.gmail.com>
[not found] ` <CANU+ZydyKsctuFjPfBz7PuS=FaUtK0gs5Lq06pL5nuRJKe+J0w@mail.gmail.com>
2021-05-24 8:32 ` Baoquan He
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=20210407140316.30210-1-lijiang@redhat.com \
--to=lijiang@redhat.com \
--cc=andy@infradead.org \
--cc=ardb@kernel.org \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=dvhart@infradead.org \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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).