kernel/git/next/linux-next.git/mm/execmem.c, branch master

mm/execmem: use VM_FLUSH_RESET_PERMS for ROX cache allocations

2026-09-09T06:30:21+00:00

Initially execmem completely removed direct map alias for the memory allocated for the ROX cache in PMD_SIZE chunks. When that memory was freed, its direct map was restored also in PMD_SIZE chunks to avoid fragmentation of the direct map caused by vmalloc::vm_reset_perms(). This required execmem to implement the wrappers for set_direct_map APIs for proper sequencing of removal and restoration of the direct map aliases. Since then x86's CPA gained support for collapsing the direct map page tables for ROX pages and execmem switched from removing ROX caches from the direct map to making them ROX there, so execmem only needs to update direct map alias permissions when freeing the ROX cache memory. vmalloc already handles those updates for areas with VM_FLUSH_RESET_PERMS set and vmalloc::vm_reset_perms() does not force split of the direct map for PMD_SIZE chunks. Set the area permissions with set_vm_flush_reset_perms() when populating the execmem cache just before flipping the area to ROX. This way freeing an allocated area on an error path won't incur two updates of the direct map alias of that area and TLB flushing in vm_reset_perms(). Link: https://lore.kernel.org/20260903-execmem-set-vm-perms-v0-2-v3-5-949b64a9f755@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Cc: Albert Ou Cc: Alexander Gordeev Cc: Alexandre Ghiti Cc: Andy Lutomirski Cc: "Borislav Petkov (AMD)" Cc: Brendan Jackman Cc: Catalin Marinas Cc: Christian Borntraeger Cc: Dave Hansen Cc: David Hildenbrand Cc: Gerald Schaefer Cc: Heiko Carstens Cc: "H. Peter Anvin" Cc: Huacai Chen Cc: Ingo Molnar Cc: Len Brown Cc: Palmer Dabbelt Cc: Peter Zijlstra Cc: "Rafael J. Wysocki" Cc: Ryan Roberts Cc: Sven Schnelle Cc: "Uladzislau Rezki (Sony)" Cc: Vasily Gorbik Cc: WANG Xuerui Cc: Will Deacon Cc: Dev Jain Signed-off-by: Andrew Morton

mm: split out vmalloc declarations from internal.h

2026-08-05T02:18:46+00:00

mm/internal.h becomes more and more bloated. Move declarations related to vmalloc to a new mm/vmalloc.h header. No functional changes. Link: https://lore.kernel.org/20260709-internal-h-v2-3-695631425968@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Acked-by: Muchun Song Acked-by: Vlastimil Babka (SUSE) Acked-by: David Hildenbrand (Arm) Acked-by: Lorenzo Stoakes Acked-by: Pratyush Yadav Acked-by: SJ Park Cc: Alexander Graf Cc: Alexander Potapenko Cc: Brendan Jackman Cc: Brendan Jackman Cc: Dennis Zhou Cc: Dmitry Vyukov Cc: Johannes Weiner Cc: Liam R. Howlett Cc: Marco Elver Cc: Michal Hocko Cc: Oscar Salvador Cc: Pasha Tatashin Cc: Suren Baghdasaryan Cc: Tejun Heo Cc: "Uladzislau Rezki (Sony)" Cc: Zi Yan Signed-off-by: Andrew Morton

mm/execmem: make the populate and alloc atomic

2026-04-05T20:53:34+00:00

When a block of memory is requested from the execmem manager it tries to find a suitable fragment by traversing the free_areas. In case there is no such block, a new memory area is added to the free_areas and then allocated to the caller by traversing the free_area tree again. The above operations of allocation and tree traversal are not atomic hence another request may consume this newly allocated memory block which results in the allocation failure for the original request. Such occurrence can be spotted on devices running the 6.18 kernel during the parallel modules loading. To mitigate such resource races execute the cache population and allocation operations under one mutex lock. Link: https://lkml.kernel.org/r/20260320075723.779985-1-hmazur@google.com Signed-off-by: Hubert Mazur Reviewed-by: Mike Rapoport (Microsoft) Cc: Greg Kroah-Hartman Cc: Stanislaw Kardach Cc: Michal Krawczyk Cc: Slawomir Rosek Cc: Hubert Mazur Signed-off-by: Andrew Morton

mm: remove PMD alignment constraint in execmem_vmalloc()

2025-09-28T18:51:31+00:00

When using vmalloc with VM_ALLOW_HUGE_VMAP flag, it will set the alignment to PMD_SIZE internally, if it deems huge mappings to be eligible. Therefore, setting the alignment in execmem_vmalloc is redundant. Apart from this, it also reduces the probability of allocation in case vmalloc fails to allocate hugepages - in the fallback case, vmalloc tries to use the original alignment and allocate basepages, which unfortunately will again be PMD_SIZE passed over from execmem_vmalloc, thus constraining the search for a free space in vmalloc region. Therefore, remove this constraint. Link: https://lkml.kernel.org/r/20250918093453.75676-1-dev.jain@arm.com Signed-off-by: Dev Jain Reviewed-by: Mike Rapoport (Microsoft) Cc: Ryan Roberts Signed-off-by: Andrew Morton

mm: correct type for vmalloc vm_flags fields

2025-08-02T19:06:13+00:00

Several functions refer to the unfortunately named 'vm_flags' field when referencing vmalloc flags, which happens to be the precise same name used for VMA flags. As a result these were erroneously changed to use the vm_flags_t type (which currently is a typedef equivalent to unsigned long). Currently this has no impact, but in future when vm_flags_t changes this will result in issues, so change the type to unsigned long to account for this. [lorenzo.stoakes@oracle.com: fixup very disguised vmalloc flags parameter] Link: https://lkml.kernel.org/r/e74dd8de-7e60-47ab-8a45-2c851f3c5d26@lucifer.local Link: https://lkml.kernel.org/r/20250729114906.55347-1-lorenzo.stoakes@oracle.com Signed-off-by: Lorenzo Stoakes Reported-by: Harry Yoo Closes: https://lore.kernel.org/all/aIgSpAnU8EaIcqd9@hyeyoo/ Reviewed-by: Pedro Falcato Acked-by: David Hildenbrand Reviewed-by: Harry Yoo Acked-by: Vlastimil Babka Cc: Jann Horn Cc: Liam Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: "Uladzislau Rezki (Sony)" Signed-off-by: Andrew Morton

execmem: drop writable parameter from execmem_fill_trapping_insns()

2025-08-02T19:06:12+00:00

After update of execmem_cache_free() that made memory writable before updating it, there is no need to update read only memory, so the writable parameter to execmem_fill_trapping_insns() is not needed. Drop it. Link: https://lkml.kernel.org/r/20250713071730.4117334-7-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Acked-by: Peter Zijlstra (Intel) Cc: Daniel Gomez Cc: Masami Hiramatsu (Google) Cc: Petr Pavlu Cc: Steven Rostedt (Google) Signed-off-by: Andrew Morton

execmem: add fallback for failures in vmalloc(VM_ALLOW_HUGE_VMAP)

2025-08-02T19:06:11+00:00

When execmem populates ROX cache it uses vmalloc(VM_ALLOW_HUGE_VMAP). Although vmalloc falls back to allocating base pages if high order allocation fails, it may happen that it still cannot allocate enough memory. Right now ROX cache is only used by modules and in majority of cases the allocations happen at boot time when there's plenty of free memory, but upcoming enabling ROX cache for ftrace and kprobes would mean that execmem allocations can happen when the system is under memory pressure and a failure to allocate large page worth of memory becomes more likely. Fallback to regular vmalloc() if vmalloc(VM_ALLOW_HUGE_VMAP) fails. Link: https://lkml.kernel.org/r/20250713071730.4117334-6-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Acked-by: Peter Zijlstra (Intel) Cc: Daniel Gomez Cc: Masami Hiramatsu (Google) Cc: Petr Pavlu Cc: Steven Rostedt (Google) Signed-off-by: Andrew Morton

execmem: move execmem_force_rw() and execmem_restore_rox() before use

2025-08-02T19:06:11+00:00

to avoid static declarations. Link: https://lkml.kernel.org/r/20250713071730.4117334-5-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Acked-by: Peter Zijlstra (Intel) Cc: Daniel Gomez Cc: Masami Hiramatsu (Google) Cc: Petr Pavlu Cc: Steven Rostedt (Google) Signed-off-by: Andrew Morton

execmem: rework execmem_cache_free()

2025-08-02T19:06:11+00:00

Currently execmem_cache_free() ignores potential allocation failures that may happen in execmem_cache_add(). Besides, it uses text poking to fill the memory with trapping instructions before returning it to cache although it would be more efficient to make that memory writable, update it using memcpy and then restore ROX protection. Rework execmem_cache_free() so that in case of an error it will defer freeing of the memory to a delayed work. With this the happy fast path will now change permissions to RW, fill the memory with trapping instructions using memcpy, restore ROX permissions, add the memory back to the free cache and clear the relevant entry in busy_areas. If any step in the fast path fails, the entry in busy_areas will be marked as pending_free. These entries will be handled by a delayed work and freed asynchronously. To make the fast path faster, use __GFP_NORETRY for memory allocations and let asynchronous handler try harder with GFP_KERNEL. Link: https://lkml.kernel.org/r/20250713071730.4117334-4-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Acked-by: Peter Zijlstra (Intel) Cc: Daniel Gomez Cc: Masami Hiramatsu (Google) Cc: Petr Pavlu Cc: Steven Rostedt (Google) Signed-off-by: Andrew Morton

execmem: introduce execmem_alloc_rw()

2025-08-02T19:06:11+00:00

Some callers of execmem_alloc() require the memory to be temporarily writable even when it is allocated from ROX cache. These callers use execemem_make_temp_rw() right after the call to execmem_alloc(). Wrap this sequence in execmem_alloc_rw() API. Link: https://lkml.kernel.org/r/20250713071730.4117334-3-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Reviewed-by: Daniel Gomez Reviewed-by: Petr Pavlu Acked-by: Peter Zijlstra (Intel) Cc: Masami Hiramatsu (Google) Cc: Steven Rostedt (Google) Signed-off-by: Andrew Morton