5.10-stable patches

added patches:
	revert-x86-setup-don-t-remove-e820_type_ram-for-pfn-0.patch

diff --git a/queue-5.10/revert-x86-setup-don-t-remove-e820_type_ram-for-pfn-0.patch b/queue-5.10/revert-x86-setup-don-t-remove-e820_type_ram-for-pfn-0.patch
new file mode 100644 (file)
index 0000000..f4b9c60
--- /dev/null
+++ b/queue-5.10/revert-x86-setup-don-t-remove-e820_type_ram-for-pfn-0.patch
@@ -0,0 +1,66 @@
+From 5c279c4cf206e03995e04fd3404fa95ffd243a97 Mon Sep 17 00:00:00 2001
+From: Mike Rapoport <rppt@linux.ibm.com>
+Date: Thu, 4 Feb 2021 20:12:37 +0200
+Subject: Revert "x86/setup: don't remove E820_TYPE_RAM for pfn 0"
+
+From: Mike Rapoport <rppt@linux.ibm.com>
+
+commit 5c279c4cf206e03995e04fd3404fa95ffd243a97 upstream.
+
+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.
+
+Link: 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>
+Cc: stable@kernel.org
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/setup.c |   20 +++++++++++---------
+ 1 file changed, 11 insertions(+), 9 deletions(-)
+
+--- a/arch/x86/kernel/setup.c
++++ b/arch/x86/kernel/setup.c
+@@ -666,6 +666,17 @@ static void __init trim_platform_memory_
+ 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.
+        * take them out.
+@@ -722,15 +733,6 @@ early_param("reservelow", parse_reservel
+ 
+ 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));
+ }
+       

diff --git a/queue-5.10/series b/queue-5.10/series
index 302cd68d2bc3eefa99edb0752f77ff2d1e632f91..884419ee6af995ed4bc156011d3fbccf77b3b0e1 100644 (file)
--- a/queue-5.10/series
+++ b/queue-5.10/series
@@ -12,3 +12,4 @@ drm-panfrost-support-cache-coherent-integrations.patch
 arm64-dts-meson-describe-g12b-gpu-as-coherent.patch
 arm64-fix-kernel-address-detection-of-__is_lm_address.patch
 arm64-do-not-pass-tagged-addresses-to-__is_lm_address.patch
+revert-x86-setup-don-t-remove-e820_type_ram-for-pfn-0.patch