From: Mike Rapoport <firstname.lastname@example.org>
To: Linus Torvalds <email@example.com>
Cc: Chris Wilson <firstname.lastname@example.org>,
Andrew Morton <email@example.com>,
Linux Kernel Mailing List <firstname.lastname@example.org>,
Subject: Re: Linux 5.11-rc5
Date: Thu, 4 Feb 2021 20:19:25 +0200 [thread overview]
Message-ID: <20210204181925.GL299309@linux.ibm.com> (raw)
On Mon, Jan 25, 2021 at 12:49:39PM -0800, Linus Torvalds wrote:
> On Mon, Jan 25, 2021 at 12:35 PM Chris Wilson <email@example.com> wrote:
> Mike: should we perhaps revert the first patch too (commit
> bde9cfa3afe4: "x86/setup: don't remove E820_TYPE_RAM for pfn 0")?
Unfortunately, I was too optimistic and didn't take into account that this
commit changes the way /dev/mem sees the first page of memory.
There were reports of slackware users about issues with lilo after upgrade
from 5.10.11 to 5.10.12
The root cause is that lilo is no longer able to access the first memory
page via /dev/mem because its type was changed from E820_TYPE_RESERVED to
E820_TYPE_RAM, so this became a part of the "System RAM" resource and
devmem_is_allowed() considers it disallowed area.
So here's the revert of bde9cfa3afe4 as well.
From a7fdc4117010d393dd77b99da5b573a5c98453ce Mon Sep 17 00:00:00 2001
From: Mike Rapoport <firstname.lastname@example.org>
Date: Thu, 4 Feb 2021 20:12:37 +0200
Subject: [PATCH] Revert "x86/setup: don't remove E820_TYPE_RAM for pfn 0"
This reverts commit bde9cfa3afe4324ec251e4af80ebf9b7afaf7afe.
Changing the first memory page type from E820_TYPE_RESERVED to
E820_TYPE_RAM makes it a part of "System RAM" resource rather than a
reserved resource and this in turn causes devmem_is_allowed() to treat is
as area that can be accessed but it is filled with zeroes instead of the
actual data as previously.
The change in /dev/mem output causes lilo to fail as was reported at
slakware users forum , and probably other legacy applications will
experience similar problems.
Signed-off-by: Mike Rapoport <email@example.com>
arch/x86/kernel/setup.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 3412c4595efd..740f3bdb3f61 100644
@@ -660,6 +660,17 @@ static void __init trim_platform_memory_ranges(void)
static void __init trim_bios_range(void)
+ * A special case is the first 4Kb of memory;
+ * This is a BIOS owned area, not kernel ram, but generally
+ * not listed as such in the E820 table.
+ * This typically reserves additional memory (64KiB by default)
+ * since some BIOSes are known to corrupt low memory. See the
+ * Kconfig help text for X86_RESERVE_LOW.
+ e820__range_update(0, PAGE_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
* special case: Some BIOSes report the PC BIOS
* area (640Kb -> 1Mb) as RAM even though it is not.
@@ -717,15 +728,6 @@ early_param("reservelow", parse_reservelow);
static void __init trim_low_memory_range(void)
- * A special case is the first 4Kb of memory;
- * This is a BIOS owned area, not kernel ram, but generally
- * not listed as such in the E820 table.
- * This typically reserves additional memory (64KiB by default)
- * since some BIOSes are known to corrupt low memory. See the
- * Kconfig help text for X86_RESERVE_LOW.
memblock_reserve(0, ALIGN(reserve_low, PAGE_SIZE));
next prev parent reply other threads:[~2021-02-04 18:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 1:06 Linux 5.11-rc5 Linus Torvalds
2021-01-25 3:48 ` Guenter Roeck
2021-01-25 3:56 ` Bhaskar Chowdhury
2021-01-25 4:06 ` Guenter Roeck
2021-01-25 4:11 ` Bhaskar Chowdhury
2021-01-25 20:34 ` Chris Wilson
2021-01-25 20:49 ` Linus Torvalds
2021-01-25 21:33 ` Mike Rapoport
2021-01-25 21:46 ` Chris Wilson
2021-01-26 9:33 ` Chris Wilson
2021-01-26 16:24 ` Mike Rapoport
2021-01-26 18:45 ` Linus Torvalds
2021-01-27 9:38 ` Greg KH
2021-02-04 18:19 ` Mike Rapoport [this message]
2021-02-04 18:32 ` Linus Torvalds
2021-02-05 6:54 ` Greg KH
2021-01-25 21:04 ` Mike Rapoport
2021-01-25 21:13 ` Chris Wilson
2021-01-26 16:37 ` Mike Rapoport
2021-01-28 21:00 ` Pavel Machek
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.