kernel/git/next/linux-next.git/arch/loongarch/include, branch master

Merge branch 'mm-nonmm-unstable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2026-09-14T13:51:59+00:00

# Conflicts: # init/main.c

Merge https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable into for-next

2026-09-14T07:56:18+00:00

Signed-off-by: David Hildenbrand (Arm)

init, arch: make CONFIG_COMMAND_LINE_SIZE globally configurable

2026-09-14T04:33:29+00:00

Currently, s390 has the ability to configure the maximum kernel command line size via Kconfig (CONFIG_COMMAND_LINE_SIZE). Other architectures define a hardcoded COMMAND_LINE_SIZE macro in their setup.h headers. In some use cases, such as netboot kernels, rootfs configurations, or larger initramfs setups, a larger command line size is required. While for embedded workloads, it can be reduced to save memory. Move CONFIG_COMMAND_LINE_SIZE out of arch/s390/Kconfig and into init/Kconfig under General setup, and update every architecture's setup.h header to define COMMAND_LINE_SIZE as CONFIG_COMMAND_LINE_SIZE. For user-space API (uapi) headers, wrap the definition in an `#ifdef __KERNEL__` guard and retain the historical hardcoded default in the `#else` block. When user-space headers are installed via `make headers_install`, unifdef strips out the kernel section, ensuring the same value as before for user-space applications including ``. For S390, the range is kept the same, but other architectures have varying constraints. S390 requires a minimum of 896 bytes to protect legacy bootloaders from overwriting the .text section. ARM, M68K, and NIOS2 allocate the command line directly on severely constrained decompressor stacks, so their ranges are strictly capped at 2048 bytes to prevent deterministic stack exhaustion and boot panics. PowerPC (PPC) boot wrappers silently truncate arguments past 2048 bytes, so it is also capped at 2048 to prevent silent parameter loss. The SuperH (SUPERH) boot parameter page allocates exactly PAGE_SIZE (typically 4096 bytes), and placing a 4096-byte command line starting at offset 256 would cause strscpy() to read out of bounds; it is capped at 3840 bytes. Alpha physically limits its boot parameter block to 256 bytes, so its limit is strictly locked to 256. All other architectures are capped at 4096 bytes to prevent unreasonable allocations. Link: https://lore.kernel.org/20260818231646.804507-2-wfelipe@google.com Signed-off-by: Maciej Żenczykowski Signed-off-by: Wilson Felipe Pereira Signed-off-by: Andrew Morton Cc: Albert Ou Cc: Alexander Gordeev Cc: Alexandre Ghiti Cc: Arnd Bergmann Cc: Christian Borntraeger Cc: Heiko Carstens Cc: Palmer Dabbelt Cc: Sven Schnelle Cc: Vasily Gorbik

mm: drop pxd_ERROR()

2026-09-14T04:31:43+00:00

There are no more users left for any pxd_ERROR() either in generic MM or in the platform MM. Hence all these platform macros along with their generic fallback could be dropped across the tree. Link: https://lore.kernel.org/20260831054331.625505-9-anshuman.khandual@arm.com Signed-off-by: Anshuman Khandual Signed-off-by: Andrew Morton Acked-by: Geert Uytterhoeven # m68k Acked-by: David Hildenbrand (Arm) Acked-by: Mike Rapoport (Microsoft) Cc: Helge Deller Cc: Huacai Chen Cc: James Bottomley Cc: John Paul Adrian Glaubitz Cc: Lorenzo Stoakes Cc: Rich Felker Cc: Samuel Holland Cc: WANG Xuerui Cc: Yoshinori Sato

loongarch/mm: stop using pte_ERROR()

2026-09-14T04:31:42+00:00

Directly use pr_err() in __set_fixmap() and drop pte_ERROR() which helps in eventually dropping pte_ERROR() macro across the tree. In this new printing __FILE__ and __LINE__ has been dropped because they are always the same and don't really add any value. The new ptval_to_str() helper is being used for converting pgtable entry value into a string. The error message itself has been cleaned up as well. Link: https://lore.kernel.org/20260831054331.625505-4-anshuman.khandual@arm.com Signed-off-by: Anshuman Khandual Signed-off-by: Andrew Morton Acked-by: David Hildenbrand (Arm) Acked-by: Mike Rapoport (Microsoft) Cc: Huacai Chen Cc: WANG Xuerui Cc: Geert Uytterhoeven Cc: Helge Deller Cc: James Bottomley Cc: John Paul Adrian Glaubitz Cc: Lorenzo Stoakes Cc: Rich Felker Cc: Samuel Holland Cc: Yoshinori Sato

Revert "arch: introduce set_direct_map_valid_noflush()"

2026-09-14T04:31:16+00:00

Commit 0c6378a71574 ("arch: introduce set_direct_map_valid_noflush()") added set_direct_map_valid_noflush() to allow updating the direct map for a physically contiguous range in execmem. As Brendan recently pointed out [1], this API is confusing because on arm64 it means that is sets VALID bit in ptes, while on other architectures it is an analog of set_direct_map_default_noflush(). The only user of set_direct_map_valid_noflush() was execmem's ROX cache freeing path and it was switched to utilize VM_FLUSH_RESET_PERMS for resetting permissions of the direct map alias. With the last user gone and with set_direct_map_{invalid,default}_noflush() accepting number of pages as a parameter, set_direct_map_valid_noflush() become a copy of set_memory_valid() on arm64 and a duplicate of set_direct_map_{invalid,default}_noflush() on other architecture, it is safe to remove set_direct_map_valid_noflush(). Also drop a stale comment in arm64::__kernel_map_pages() that Linus bothered to add when merging changes containing set_direct_map_valid_noflush() to his tree. This reverts commit 0c6378a71574daa6cd1534ad42a956e3262756c7. Link: https://lore.kernel.org/20260903-execmem-set-vm-perms-v0-2-v3-6-949b64a9f755@kernel.org Link: https://lore.kernel.org/all/DJ69RCVRBO0Y.3JCYSW50IC4RC@linux.dev [1] Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Andrew Morton Reviewed-by: Brendan Jackman Acked-by: David Hildenbrand (Arm) Cc: Albert Ou Cc: Alexander Gordeev Cc: Alexandre Ghiti Cc: Andy Lutomirski Cc: "Borislav Petkov (AMD)" Cc: Catalin Marinas Cc: Christian Borntraeger Cc: Dave Hansen 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

set_memory: add number of pages parameter to set_direct_map APIs

2026-09-14T04:31:15+00:00

Patch series "arch, mm/execmem: resolve confusion about set_direct_map_valid_noflush()", v3. Recent discussion about implementation of execmem's ROX caches on arm64 revealed a confusion about how set_direct_map_valid_noflush() implemented on different architectures. On arm64 it sets or clears the PTE_VALID bit marking a PTE as present or not present. On other architectures it's a range version of set_direct_map_invalid_noflush() and set_direct_map_default_noflush() Unlike arm64::set_direct_map_valid_noflush(), set_direct_map_default_noflush() not only marks PTE as present, but also sets its default protection mode. Other than that, initial design of execmem ROX caches didn't rely on restoration of large mappings that's now available on x86, but completely removed the memory allocated for the ROX cache from the direct map to ensure that large mappings are not split. This precluded usage of VM_FLUSH_RESET_PERMS for the ROX cache allocations and required execmem to implement manipulation of the direct map alias. Current implementation of ROX caches does not remove the direct map alias but simply calls set_memory_rox() that updates the permissions in both vmalloc address space and the direct map and relies on collapse_large_pages() in x86 CPA to keep large mappings. This allow using VM_FLUSH_RESET_PERMS for execmem ROX cache allocations with small adjustments to set_direct_map APIs and vmalloc::reset_perms() behaviour: adding number of pages parameter to set_direct_map APIs and making resetting of the direct map permissions in vmalloc VMAP_HUGE friendly. Implement these adjustments, make execmem always use VM_FLUSH_RESET_PERMS and revert set_direct_map_valid_noflush() changes. This patch (of 6): When set_direct_map APIs were introduced by the commit d253ca0c3865 ("x86/mm/cpa: Add set_direct_map_*() functions") the single page parameter made sense because the initial callers (vmalloc and hibernation) had sets of unsorted struct pages that required changes of their mappings in the direct map. Since there is an increasing demand for direct map manipulation and it is also desirable to be able to update larger physically contiguous mappings, for example an entire large folio, extend set_direct_map APIs to receive number of pages parameter. As there is still only a handful of callers, change the existing functions directly and update all the call sites rather than adding wrappers for single page case. Link: https://lore.kernel.org/20260903-execmem-set-vm-perms-v0-2-v3-0-949b64a9f755@kernel.org Link: https://lore.kernel.org/20260903-execmem-set-vm-perms-v0-2-v3-1-949b64a9f755@kernel.org Link: https://lore.kernel.org/all/20260611130144.1385343-4-abarnas@google.com [1] Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Andrew Morton Acked-by: David Hildenbrand (Arm) 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: 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

LoongArch: KVM: Fix TOCTOU race on pv_features

2026-09-04T13:45:13+00:00

In kvm_loongarch_cpucfg_set_attr() the check-then-set on kvm->arch.pv_features is lockless, so two vCPUs can race past the validation and set different values. Add a spinlock to protect it. Cc: stable@vger.kernel.org Reviewed-by: Bibo Mao Signed-off-by: Tao Cui Signed-off-by: Huacai Chen

LoongArch: KVM: Remove unused function kvm_arch_flush_remote_tlbs_memslot()

2026-09-04T13:44:54+00:00

Function kvm_arch_flush_remote_tlbs_memslot() is not called any more, so remove this API. Reviewed-by: Tao Cui Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen

LoongArch: KVM: Add unregister helpers for the KVM interrupt devices

2026-09-04T13:44:53+00:00

The IPI/EIOINTC/PCH-PIC/DMSINTC KVM devices each have a helper that registers their kvm_device_ops, but there is no counterpart to remove them, so a caller that needs to undo a registration has to open-code kvm_unregister_device_ops() with the matching device type. Add kvm_loongarch_unregister_{ipi,eiointc,pch_pic,dmsintc}_device() next to the existing register helpers. kvm_unregister_device_ops() is a no-op when the corresponding device type is not currently registered. No functional change, as there are no callers yet. Cc: stable@vger.kernel.org Suggested-by: Bibo Mao Reviewed-by: Bibo Mao Signed-off-by: Chaithanya Lagisetty Signed-off-by: Huacai Chen