lkml.org 
[lkml]   [2021]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: Linux 5.11-rc5
On Mon, Jan 25, 2021 at 12:49:39PM -0800, Linus Torvalds wrote:
> On Mon, Jan 25, 2021 at 12:35 PM Chris Wilson <chris@chris-wilson.co.uk> 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

https://www.linuxquestions.org/questions/slackware-14/slackware-current-lilo-vesa-warnings-after-recent-updates-4175689617/#post6214439

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 <rppt@linux.ibm.com>
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 [1], and probably other legacy applications will
experience similar problems.

[1] https://www.linuxquestions.org/questions/slackware-14/slackware-current-lilo-vesa-warnings-after-recent-updates-4175689617/#post6214439

Signed-off-by: Mike Rapoport <rppt@linux.ibm.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
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -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));
}

--
2.29.2




> Linus

--
Sincerely yours,
Mike.

\
 
 \ /
  Last update: 2021-02-04 19:23    [W:0.186 / U:3.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site