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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> --- 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.
