linux-kernel - [PATCH 0/4] x86/mm: replace GFP_ATOMIC with GFP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20211111110241.25968-1-rppt@kernel.org>
Date:   Thu, 11 Nov 2021 13:02:37 +0200
From:   Mike Rapoport <rppt@...nel.org>
To:     x86@...nel.org
Cc:     Andy Lutomirski <luto@...nel.org>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Mike Rapoport <rppt@...nel.org>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Rick Edgecombe <rick.p.edgecombe@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org
Subject: [PATCH 0/4] x86/mm: replace GFP_ATOMIC with GFP_KERNEL for direct map allocations

From: Mike Rapoport <rppt@...ux.ibm.com>

Hi,

The direct map pages on x86 that are allocated using alloc_low_pages() and
spp_getpage() functions. When these functions take 'after_bootmem' branch,
the memory is allocated from buddy with GFP_ATOMIC and I could not find any
reason for this.

Since most of the kernel page tables are anyway allocated really early,
only GART IOMMU initialization and memory hotplug would actually use
get_free_pages() to allocate direct map entries and neither of them happen
in an atomic context, so it would be fine to use GFP_KERNEL. This will give
the page allocator more flexibility when memory hotplug creates the direct
map for hot-added memory and won't use precious atomic memory resources.

The first three patches are trivial cleanups I've encountered while
analysing call paths of alloc_low_pages() and spp_getpage() and the fourth
patch actually replaces GFP_ATOMIC with GFP_KERNEL in those functions.

Mike Rapoport (4):
  x86/mm: make init_trampoline_kaslr() __init
  x86/mm: make kernel_physical_mapping_change() __init
  x86/mm: init_64: make set_pte_vaddr_p4d static
  x86/mm: replace GFP_ATOMIC with GFP_KERNEL for direct map allocations

 arch/x86/include/asm/pgtable_64.h | 1 -
 arch/x86/mm/init.c                | 2 +-
 arch/x86/mm/init_64.c             | 7 ++++---
 arch/x86/mm/kaslr.c               | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

base-commit: d2f38a3c6507b2520101f9a3807ed98f1bdc545a
-- 
2.28.0