summaryrefslogtreecommitdiff
path: root/io_uring
diff options
context:
space:
mode:
authorSteve Wahl <steve.wahl@hpe.com>2024-01-26 19:48:41 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2024-02-23 11:12:43 +0300
commitaedcefae6c18f6d7b2c75c1a40d5731004929621 (patch)
tree0c84af00d6426143612bbf90cbec6df946cd3067 /io_uring
parent3863ca052216d893d21ac42b75c2db8a0bd49689 (diff)
downloadlinux-aedcefae6c18f6d7b2c75c1a40d5731004929621.tar.xz
x86/mm/ident_map: Use gbpages only where full GB page should be mapped.
commit d794734c9bbfe22f86686dc2909c25f5ffe1a572 upstream. When ident_pud_init() uses only gbpages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. On UV systems, this ends up including regions that will cause hardware to halt the system if accessed (these are marked "reserved" by BIOS). Even processor speculation into these regions is enough to trigger the system halt. Only use gbpages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full gbpage. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence. [ dhansen: fix up comment formatting, simplifty changelog ] Signed-off-by: Steve Wahl <steve.wahl@hpe.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20240126164841.170866-1-steve.wahl%40hpe.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'io_uring')
0 files changed, 0 insertions, 0 deletions