kernel/linux.git/arch/arm/mm, branch v5.15.208

ARM: 9467/1: mm: Don't use %pK through printk

2026-03-04T12:20:19+00:00

[ Upstream commit 012ea376a5948b025f260aa45d2a6ec5d96674ea ] Restricted pointers ("%pK") were never meant to be used through printk(). They can acquire sleeping locks in atomic contexts. Switch to %px over the more secure %p as this usage is a debugging aid, gated behind CONFIG_DEBUG_VIRTUAL and used by WARN(). Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/ Signed-off-by: Thomas Weißschuh Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin

minmax: add in_range() macro

2025-10-19T14:21:28+00:00

commit f9bff0e31881d03badf191d3b0005839391f5f2b upstream. Patch series "New page table range API", v6. This patchset changes the API used by the MM to set up page table entries. The four APIs are: set_ptes(mm, addr, ptep, pte, nr) update_mmu_cache_range(vma, addr, ptep, nr) flush_dcache_folio(folio) flush_icache_pages(vma, page, nr) flush_dcache_folio() isn't technically new, but no architecture implemented it, so I've done that for them. The old APIs remain around but are mostly implemented by calling the new interfaces. The new APIs are based around setting up N page table entries at once. The N entries belong to the same PMD, the same folio and the same VMA, so ptep++ is a legitimate operation, and locking is taken care of for you. Some architectures can do a better job of it than just a loop, but I have hesitated to make too deep a change to architectures I don't understand well. One thing I have changed in every architecture is that PG_arch_1 is now a per-folio bit instead of a per-page bit when used for dcache clean/dirty tracking. This was something that would have to happen eventually, and it makes sense to do it now rather than iterate over every page involved in a cache flush and figure out if it needs to happen. The point of all this is better performance, and Fengwei Yin has measured improvement on x86. I suspect you'll see improvement on your architecture too. Try the new will-it-scale test mentioned here: https://lore.kernel.org/linux-mm/20230206140639.538867-5-fengwei.yin@intel.com/ You'll need to run it on an XFS filesystem and have CONFIG_TRANSPARENT_HUGEPAGE set. This patchset is the basis for much of the anonymous large folio work being done by Ryan, so it's received quite a lot of testing over the last few months. This patch (of 38): Determine if a value lies within a range more efficiently (subtraction + comparison vs two comparisons and an AND). It also has useful (under some circumstances) behaviour if the range exceeds the maximum value of the type. Convert all the conflicting definitions of in_range() within the kernel; some can use the generic definition while others need their own definition. Link: https://lkml.kernel.org/r/20230802151406.3735276-1-willy@infradead.org Link: https://lkml.kernel.org/r/20230802151406.3735276-2-willy@infradead.org Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Andrew Morton Signed-off-by: Eliav Farber Signed-off-by: Greg Kroah-Hartman

ARM: 9447/1: arm/memremap: fix arch_memremap_can_ram_remap()

2025-06-27T10:05:24+00:00

commit 96e0b355883006554a0bee3697da475971d6bba8 upstream. arm/memremap: fix arch_memremap_can_ram_remap() commit 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map") added the definition of arch_memremap_can_ram_remap() for arm[64] specific filtering of what pages can be used from the linear mapping. memblock_is_map_memory() was called with the pfn of the address given to arch_memremap_can_ram_remap(); however, memblock_is_map_memory() expects to be given an address for arm, not a pfn. This results in calls to memremap() returning a newly mapped area when it should return an address in the existing linear mapping. Fix this by removing the address to pfn translation and pass the address directly. Fixes: 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map") Signed-off-by: Ross Stutterheim Cc: Mike Rapoport Cc: stable@vger.kernel.org Reviewed-by: Catalin Marinas Reviewed-by: Linus Walleij Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman

ARM: Remove address checking for MMUless devices

2025-04-10T12:31:56+00:00

commit 3ccea4784fddd96fbd6c4497eb28b45dab638c2a upstream. Commit 169f9102f9198b ("ARM: 9350/1: fault: Implement copy_from_kernel_nofault_allowed()") added the function to check address before use. However, for devices without MMU, addr > TASK_SIZE will always fail. This patch move this function after the #ifdef CONFIG_MMU statement. Signed-off-by: Yanjun Yang Acked-by: Ard Biesheuvel Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218953 Fixes: 169f9102f9198b ("ARM: 9350/1: fault: Implement copy_from_kernel_nofault_allowed()") Link: https://lore.kernel.org/r/20240611100947.32241-1-yangyj.ee@gmail.com Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

ARM: 9351/1: fault: Add "cut here" line for prefetch aborts

2025-04-10T12:31:56+00:00

commit 8f09b8b4fa58e99cbfd9a650b31d65cdbd8e4276 upstream. The common pattern in arm is to emit a "8<--- cut here ---" line for faults, but it was missing for do_PrefetchAbort(). Add it. Cc: Wang Kefeng Cc: Ben Hutchings Cc: linux-arm-kernel@lists.infradead.org Acked-by: Ard Biesheuvel Signed-off-by: Kees Cook Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman

ARM: 9350/1: fault: Implement copy_from_kernel_nofault_allowed()

2025-04-10T12:31:55+00:00

commit 169f9102f9198b04afffa6164372a4ba4070f412 upstream. Under PAN emulation when dumping backtraces from things like the LKDTM EXEC_USERSPACE test[1], a double fault (which would hang a CPU) would happen because of dump_instr() attempting to read a userspace address. Make sure copy_from_kernel_nofault() does not attempt this any more. Closes: https://lava.sirena.org.uk/scheduler/job/497571 Link: https://lore.kernel.org/all/202401181125.D48DCB4C@keescook/ [1] Reported-by: Mark Brown Suggested-by: Russell King (Oracle) Reviewed-by: Ard Biesheuvel Tested-by: Mark Brown Cc: Wang Kefeng Cc: Andrew Morton Cc: Ben Hutchings Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Kees Cook Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman

ARM: 9420/1: smp: Fix SMP for xip kernels

2024-12-14T18:50:41+00:00

[ Upstream commit 9e9b0cf9319b4db143014477b0bc4b39894248f1 ] Fix the physical address calculation of the following to get smp working on xip kernels. - secondary_data needed for secondary cpu bootup. - secondary_startup address passed through psci. - identity mapped code region needed for enabling mmu for secondary cpus. Signed-off-by: Harith George Reviewed-by: Linus Walleij Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin

ARM: 9419/1: mm: Fix kernel memory mapping for xip kernels

2024-12-14T18:50:35+00:00

[ Upstream commit ed6cbe6e5563452f305e89c15846820f2874e431 ] The patchset introducing kernel_sec_start/end variables to separate the kernel/lowmem memory mappings, broke the mapping of the kernel memory for xipkernels. kernel_sec_start/end variables are in RO area before the MMU is switched on for xipkernels. So these cannot be set early in boot in head.S. Fix this by setting these after MMU is switched on. xipkernels need two different mappings for kernel text (starting at CONFIG_XIP_PHYS_ADDR) and data (starting at CONFIG_PHYS_OFFSET). Also, move the kernel code mapping from devicemaps_init() to map_kernel(). Fixes: a91da5457085 ("ARM: 9089/1: Define kernel physical section start and end") Signed-off-by: Harith George Reviewed-by: Linus Walleij Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin

treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_56.RULE (part 1)

2023-10-06T11:18:12+00:00

[ Upstream commit 0fdebc5ec2ca492d69df2d93a6a7abade4941aae ] Based on the normalized pattern: this file is licensed under the terms of the gnu general public license version 2 this program is licensed as is without any warranty of any kind whether express or implied extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference. Reviewed-by: Allison Randal Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 6469b2feade8 ("ARM: dts: ti: omap: Fix bandgap thermal cells addressing for omap3/4") Signed-off-by: Sasha Levin

ARM: 9280/1: mm: fix warning on phys_addr_t to void pointer assignment

2023-02-01T07:27:25+00:00

commit a4e03921c1bb118e6718e0a3b0322a2c13ed172b upstream. zero_page is a void* pointer but memblock_alloc() returns phys_addr_t type so this generates a warning while using clang and with -Wint-error enabled that becomes and error. So let's cast the return of memblock_alloc() to (void *). Cc: # 4.14.x + Fixes: 340a982825f7 ("ARM: 9266/1: mm: fix no-MMU ZERO_PAGE() implementation") Signed-off-by: Giulio Benetti Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman