Revert "x86/setup: don't remove E820_TYPE_RAM for pfn 0"
authorMike Rapoport <rppt@linux.ibm.com>
Thu, 4 Feb 2021 18:12:37 +0000 (20:12 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 7 Feb 2021 14:37:13 +0000 (15:37 +0100)
commitd9655c6854a64924f4e08918b7a7fb7a7c16c94f
tree5c720b441fafd00d516cf0762a6166b199f9d6f0
parenta2c7d0667cf3adb94b3b7e96dbc03151e97ab32e
Revert "x86/setup: don't remove E820_TYPE_RAM for pfn 0"

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