diff options
author | 2023-09-15 10:02:21 +0300 | |
---|---|---|
committer | 2023-09-17 09:48:57 +0200 | |
commit | f530ee95b72e77b09c141c4b1a4b94d1199ffbd9 (patch) | |
tree | b2119257d79e018544ac9227cd21fd65b6149bef /tools/perf/scripts/python/export-to-postgresql.py | |
parent | x86/ibt: Avoid duplicate ENDBR in __put_user_nocheck*() (diff) | |
download | wireguard-linux-f530ee95b72e77b09c141c4b1a4b94d1199ffbd9.tar.xz wireguard-linux-f530ee95b72e77b09c141c4b1a4b94d1199ffbd9.zip |
x86/boot/compressed: Reserve more memory for page tables
The decompressor has a hard limit on the number of page tables it can
allocate. This limit is defined at compile-time and will cause boot
failure if it is reached.
The kernel is very strict and calculates the limit precisely for the
worst-case scenario based on the current configuration. However, it is
easy to forget to adjust the limit when a new use-case arises. The
worst-case scenario is rarely encountered during sanity checks.
In the case of enabling 5-level paging, a use-case was overlooked. The
limit needs to be increased by one to accommodate the additional level.
This oversight went unnoticed until Aaron attempted to run the kernel
via kexec with 5-level paging and unaccepted memory enabled.
Update wost-case calculations to include 5-level paging.
To address this issue, let's allocate some extra space for page tables.
128K should be sufficient for any use-case. The logic can be simplified
by using a single value for all kernel configurations.
[ Also add a warning, should this memory run low - by Dave Hansen. ]
Fixes: 34bbb0009f3b ("x86/boot/compressed: Enable 5-level paging during decompression stage")
Reported-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20230915070221.10266-1-kirill.shutemov@linux.intel.com
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions