diff options
author | Mike Rapoport <rppt@linux.ibm.com> | 2021-02-04 20:12:37 +0200 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2021-02-04 10:26:53 -0800 |
commit | 5c279c4cf206e03995e04fd3404fa95ffd243a97 (patch) | |
tree | 746b46f6bab34dc4057d81deda7ea6bed0cc9410 /fs/hugetlbfs | |
parent | 927002ed29e2dda6dfacb87fe582d5495a03f096 (diff) | |
download | linux-5c279c4cf206e03995e04fd3404fa95ffd243a97.tar.bz2 |
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.
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>
Diffstat (limited to 'fs/hugetlbfs')
0 files changed, 0 insertions, 0 deletions