kernel.git/arch/s390, branch linux-6.15.y

mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd()

2025-08-20T16:36:33Z

commit 59305202c67fea50378dcad0cc199dbc13a0e99a upstream. Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful. But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems. To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernel_page_tables. Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pages which in turn calls ptdump_check_wx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdump_check_wx() which will benefit both the scenarios. Drop get_online_mems() and put_online_mems() combination from all existing platform ptdump code paths. Link: https://lkml.kernel.org/r/20250620052427.2092093-1-anshuman.khandual@arm.com Fixes: bbd6ec605c0f ("arm64/mm: Enable memory hot remove") Signed-off-by: Anshuman Khandual Acked-by: David Hildenbrand Reviewed-by: Dev Jain Acked-by: Alexander Gordeev [s390] Cc: Catalin Marinas Cc: Will Deacon Cc: Ryan Roberts Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Alexander Gordeev Cc: Gerald Schaefer Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Christian Borntraeger Cc: Sven Schnelle Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

s390/early: Copy last breaking event address to pt_regs

2025-08-20T16:36:06Z

[ Upstream commit 7cf636c99b257c1b4b12066ab34fd5f06e8d892f ] In case of an early crash the early program check handler also prints the last breaking event address which is contained within the pt_regs structure. However it is not initialized, and therefore a more or less random value is printed in case of a crash. Copy the last breaking event address from lowcore to pt_regs in case of an early program check to address this. This also makes it easier to analyze early crashes. Reviewed-by: Alexander Gordeev Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin

s390/stp: Remove udelay from stp_sync_clock()

2025-08-20T16:36:06Z

[ Upstream commit b367017cdac21781a74eff4e208d3d38e1f38d3f ] When an stp sync check is handled on a system with multiple cpus each cpu gets a machine check but only the first one actually handles the sync operation. All other CPUs spin waiting for the first one to finish with a short udelay(). But udelay can't be used here as the first CPU modifies tod_clock_base before performing the sync op. During this timeframe get_tod_clock_monotonic() might return a non-monotonic time. The time spent waiting should be very short and udelay is a busy loop anyways, therefore simply remove the udelay. Reviewed-by: Heiko Carstens Signed-off-by: Sven Schnelle Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin

s390/time: Use monotonic clock in get_cycles()

2025-08-20T16:36:02Z

[ Upstream commit 09e7e29d2b49ba84bcefb3dc1657726d2de5bb24 ] Otherwise the code might not work correctly when the clock is changed. Signed-off-by: Sven Schnelle Reviewed-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin

s390/mm: Remove possible false-positive warning in pte_free_defer()

2025-08-15T10:17:07Z

commit 5647f61ad9171e8f025558ed6dc5702c56a33ba3 upstream. Commit 8211dad627981 ("s390: add pte_free_defer() for pgtables sharing page") added a warning to pte_free_defer(), on our request. It was meant to warn if this would ever be reached for KVM guest mappings, because the page table would be freed w/o a gmap_unlink(). THP mappings are not allowed for KVM guests on s390, so this should never happen. However, it is possible that the warning is triggered in a valid case as false-positive. s390_enable_sie() takes the mmap_lock, marks all VMAs as VM_NOHUGEPAGE and splits possibly existing THP guest mappings. mm->context.has_pgste is set to 1 before that, to prevent races with the mm_has_pgste() check in MADV_HUGEPAGE. khugepaged drops the mmap_lock for file mappings and might run in parallel, before a vma is marked VM_NOHUGEPAGE, but after mm->context.has_pgste was set to 1. If it finds file mappings to collapse, it will eventually call pte_free_defer(). This will trigger the warning, but it is a valid case because gmap is not yet set up, and the THP mappings will be split again. Therefore, remove the warning and the comment. Fixes: 8211dad627981 ("s390: add pte_free_defer() for pgtables sharing page") Cc: # 6.6+ Reviewed-by: Alexander Gordeev Reviewed-by: Claudio Imbrenda Signed-off-by: Gerald Schaefer Signed-off-by: Alexander Gordeev Signed-off-by: Greg Kroah-Hartman

s390/boot: Fix startup debugging log

2025-08-15T10:17:01Z

[ Upstream commit e29409faec87ffd2de2ed20b6109f303f129281b ] Fix 'kernel image' end address for kaslr case. Fixes: ec6f9f7e5bbf ("s390/boot: Add startup debugging support") Reviewed-by: Alexander Gordeev Signed-off-by: Mikhail Zaslonko Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin

s390/mm: Allocate page table with PAGE_SIZE granularity

2025-08-15T10:17:00Z

[ Upstream commit daa8af80d283ee9a7d42dd6f164a65036665b9d4 ] Make vmem_pte_alloc() consistent by always allocating page table of PAGE_SIZE granularity, regardless of whether page_table_alloc() (with slab) or memblock_alloc() is used. This ensures page table can be fully freed when the corresponding page table entries are removed. Fixes: d08d4e7cd6bf ("s390/mm: use full 4KB page for 2KB PTE") Reviewed-by: Heiko Carstens Reviewed-by: Alexander Gordeev Signed-off-by: Sumanth Korikkar Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin

s390/mm: Set high_memory at the end of the identity mapping

2025-08-15T10:16:58Z

[ Upstream commit 56f4cfab1c93b14da422cdcd23898eb008033696 ] The value of high_memory variable is set by set_high_memory() function to a value returned by memblock_end_of_DRAM(). The latter function returns by default the upper bound of the last online memory block, not the upper bound of the directly mapped memory region. As result, in case the end of memory happens to be offline, high_memory variable is set to a value that is short on the last offline memory blocks size: RANGE SIZE STATE REMOVABLE BLOCK 0x0000000000000000-0x000000ffffffffff 1T online yes 0-511 0x0000010000000000-0x0000011fffffffff 128G offline 512-575 Memory block size: 2G Total online memory: 1T Total offline memory: 128G crash> p/x vm_layout $1 = { kaslr_offset = 0x3453e918000, kaslr_offset_phys = 0xa534218000, identity_base = 0x0, identity_size = 0x12000000000 } crash> p/x high_memory $2 = 0x10000000000 In the past the value of high_memory was derived from max_low_pfn, which in turn was derived from the identity_size. Since identity_size accommodates the whole memory size - including tailing offline blocks, the offlined blocks did not impose any problem. But since commit e120d1bc12da ("arch, mm: set high_memory in free_area_init()") the value of high_memory is derived from the last memblock online region, and that is where the problem comes from. The value of high_memory is used by several drivers and by external tools (e.g. crash tool aborts while loading a dump). Similarily to ARM, use the override path provided by set_high_memory() function and set the value of high_memory at the end of the identity mapping early. That forces set_high_memory() to leave in high_memory the correct value, even when the end of available memory is offline. Fixes: e120d1bc12da ("arch, mm: set high_memory in free_area_init()") Tested-by: Mikhail Zaslonko Reviewed-by: Heiko Carstens Reviewed-by: Gerald Schaefer Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin

s390/ap: Unmask SLCF bit in card and queue ap functions sysfs

2025-08-15T10:16:58Z

[ Upstream commit 123b7c7c2ba725daf3bfa5ce421d65b92cb5c075 ] The SLCF bit ("stateless command filtering") introduced with CEX8 cards was because of the function mask's default value suppressed when user space read the ap function for an AP card or queue. Unmask this bit so that user space applications like lszcrypt can evaluate and list this feature. Fixes: d4c53ae8e494 ("s390/ap: store TAPQ hwinfo in struct ap_card") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin

s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again

2025-07-24T06:58:30Z

commit 6a5abf8cf182f577c7ae6c62f14debc9754ec986 upstream. Commit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") has accidentally removed the critical piece of commit c730fce7c70c ("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), causing intermittent kernel panics in e.g. perf's on_switch() prog to reappear. Restore the fix and add a comment. Fixes: 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") Cc: stable@vger.kernel.org Signed-off-by: Ilya Leoshkevich Link: https://lore.kernel.org/r/20250716194524.48109-2-iii@linux.ibm.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman