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

Merge branch 'headers' of git://git.infradead.org/users/willy/pagecache.git

2026-09-09T13:22:05+00:00

# Conflicts: # net/ceph/osd_client.c

Merge branch 'next' of git://git.monstr.eu/linux-2.6-microblaze.git

2026-09-09T12:02:36+00:00

mm: drop pxd_ERROR()

2026-09-09T06:30:49+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 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 Signed-off-by: Andrew Morton

microblaze: restore the ABI argument home area below pt_regs (PTO)

2026-09-01T11:50:37+00:00

The MicroBlaze ABI has the caller reserve stack space for the arguments it passes in registers: REG_PARM_STACK_SPACE is 24 and OUTGOING_REG_PARM_STACK_SPACE is 1 in the gcc backend, so a callee may write to [caller_sp + 4, caller_sp + 28). The kernel calls C functions from entry.S with r1 pointing at pt_regs, handing the callee license to spill its incoming arguments over the saved registers -- the syscall dispatch is the worst case, where the first argument slot is PT_R1, the saved user stack pointer. This was latent until GCC 15: since 3b9b8d6cfdf5 ("ira: Scale save/restore costs of callee save registers with block frequency") the allocator prefers spilling incoming arguments over copying them into callee-saved registers, and a kernel built with gcc >= 15 (without the TARGET_CALLEE_SAVE_COST workaround some distributions carry) corrupts PT_R1 on the first syscall: init takes SIGSEGV and the kernel panics. The kernel had exactly this reservation until 2011: commit 6e83557c38b4 ("microblaze: Remove r0_ram pointer and PTO alignment") removed STATE_SAVE_ARG_SPACE and with it the PTO offset, as part of cleaning up what was thought to be copied-from-v850 leftovers. Restore it: the frame is STATE_SAVE_SIZE = PT_SIZE + PTO, r1 stays at the frame base through every asm-to-C call, and the saved registers are reached at r1 + PTO + PT_*. PTO is 28 rather than the historic 24, which was one word short: FIRST_PARM_OFFSET is 4 and REG_PARM_STACK_SPACE is 24, so the area spans [sp+4, sp+28) and needs 28 bytes. With 24 the last argument slot overlapped pt_regs' r0 -- harmless only because r0 is the constant-zero register. STACK_BOUNDARY is 32 bits, so 28 needs no further rounding. Two places deliberately keep their mainline addressing. hw_exception_handler.S needs no offset change: its real-mode handler saves into the standalone pt_pool_space buffer rather than a stack frame, and _unaligned_data_exception works through a pointer to pt_regs in r7, where plain PT_* offsets are already right. And the user-SP reload after popping the frame keeps PT_R1 - PT_SIZE because PTO cancels there: (PTO + PT_R1) - (PT_SIZE + PTO) = PT_R1 - PT_SIZE. Both are exactly as the pre-2011 code had them. The instruction count is unchanged -- the same instructions with different immediates, no per-call reservation and no trampolines. The cost is 28 bytes more kernel stack per saved frame. Fixes: 6e83557c38b4 ("microblaze: Remove r0_ram pointer and PTO alignment") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Ramin Moussavi Tested-by: Waldemar Brodkorb Link: https://patch.msgid.link/20260821151809.1233057-5-ramin.moussavi@yacoub.de Signed-off-by: Michal Simek

microblaze: Fix pgd_t dependency

2026-08-23T20:45:04+00:00

asm-generic/pgtable-nop4d.h uses pgd_t so we need to include first. Presumably this is usually covered up by other includes of asm/page.h first, but a lone inclusion of linux/pgtable.h will hit this dependency problem. Signed-off-by: Matthew Wilcox (Oracle)

treewide: Remove CLOCK_TICK_RATE

2026-07-15T13:04:55+00:00

This has been scheduled for removal more than a decade ago and the comments related to it have been dutifully ignored. The last dependencies are gone. Remove it along with various now empty asm/timex.h files. Signed-off-by: Thomas Gleixner Reviewed-by: Christophe Leroy (CS GROUP) Link: https://patch.msgid.link/20260410120317.910770161@kernel.org

uaccess: unify inline vs outline copy_{from,to}_user() selection

2026-05-29T04:24:44+00:00

The kernel allows arches to select between inline and outline implementations of the copy_{from,to}_user() by defining individual INLINE_COPY_FROM_USER and INLINE_COPY_TO_USER, correspondingly. However, all arches enable or disable them always together. Without the real use-case for one helper being inlined while the other outlined, having independent controls is excessive and error prone. Switch the codebase to the single unified INLINE_COPY_USER control. Link: https://lore.kernel.org/20260425020857.356850-3-ynorov@nvidia.com Signed-off-by: Yury Norov Tested-by: Alice Ryhl Cc: Arnd Bergmann Cc: Christophe Leroy (CS GROUP) Cc: Mathieu Desnoyers Cc: Peter Zijlstra Cc: Randy Dunlap Cc: Viktor Malik Signed-off-by: Andrew Morton

ring-buffer: Flush and stop persistent ring buffer on panic

2026-05-21T12:20:58+00:00

On real hardware, panic and machine reboot may not flush hardware cache to memory. This means the persistent ring buffer, which relies on a coherent state of memory, may not have its events written to the buffer and they may be lost. Moreover, there may be inconsistency with the counters which are used for validation of the integrity of the persistent ring buffer which may cause all data to be discarded. To avoid this issue, stop recording of the ring buffer on panic and flush the cache of the ring buffer's memory. Fixes: e645535a954a ("tracing: Add option to use memmapped memory for trace boot instance") Cc: stable@vger.kernel.org Cc: Will Deacon Cc: Mathieu Desnoyers Cc: Ian Rogers Link: https://patch.msgid.link/177751969602.2136606.12031934362587643488.stgit@mhiramat.tok.corp.google.com Signed-off-by: Masami Hiramatsu (Google) Acked-by: Catalin Marinas Acked-by: Geert Uytterhoeven Signed-off-by: Steven Rostedt

mm: change to return bool for ptep_test_and_clear_young()

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

Patch series "change young flag check functions to return bool", v2. This is a cleanup patchset to change all young flag check functions to return bool, as discussed with David in the previous thread[1]. Since callers only care about whether the young flag was set, returning bool makes the intention clearer. No functional changes intended. This patch (of 6): Callers use ptep_test_and_clear_young() to clear the young flag and check whether it was set. Change the return type to bool to make the intention clearer. Link: https://lkml.kernel.org/r/cover.1774075004.git.baolin.wang@linux.alibaba.com Link: https://lkml.kernel.org/r/57e70efa9703d43959aa645246ea3cbdba14fa17.1774075004.git.baolin.wang@linux.alibaba.com Signed-off-by: Baolin Wang Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Lorenzo Stoakes (Oracle) Acked-by: David Hildenbrand (Arm) Cc: Liam Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Signed-off-by: Andrew Morton

arch, mm: consolidate empty_zero_page

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

Reduce 22 declarations of empty_zero_page to 3 and 23 declarations of ZERO_PAGE() to 4. Every architecture defines empty_zero_page that way or another, but for the most of them it is always a page aligned page in BSS and most definitions of ZERO_PAGE do virt_to_page(empty_zero_page). Move Linus vetted x86 definition of empty_zero_page and ZERO_PAGE() to the core MM and drop these definitions in architectures that do not implement colored zero page (MIPS and s390). ZERO_PAGE() remains a macro because turning it to a wrapper for a static inline causes severe pain in header dependencies. For the most part the change is mechanical, with these being noteworthy: * alpha: aliased empty_zero_page with ZERO_PGE that was also used for boot parameters. Switching to a generic empty_zero_page removes the aliasing and keeps ZERO_PGE for boot parameters only * arm64: uses __pa_symbol() in ZERO_PAGE() so that definition of ZERO_PAGE() is kept intact. * m68k/parisc/um: allocated empty_zero_page from memblock, although they do not support zero page coloring and having it in BSS will work fine. * sparc64 can have empty_zero_page in BSS rather allocate it, but it can't use virt_to_page() for BSS. Keep it's definition of ZERO_PAGE() but instead of allocating it, make mem_map_zero point to empty_zero_page. * sh: used empty_zero_page for boot parameters at the very early boot. Rename the parameters page to boot_params_page and let sh use the generic empty_zero_page. * hexagon: had an amusing comment about empty_zero_page /* A handy thing to have if one has the RAM. Declared in head.S */ that unfortunately had to go :) Link: https://lkml.kernel.org/r/20260211103141.3215197-4-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Acked-by: Helge Deller [parisc] Tested-by: Helge Deller [parisc] Reviewed-by: Christophe Leroy (CS GROUP) Acked-by: Dave Hansen Acked-by: Catalin Marinas Acked-by: Magnus Lindholm [alpha] Acked-by: Dinh Nguyen [nios2] Acked-by: Andreas Larsson [sparc] Acked-by: David Hildenbrand (Arm) Acked-by: Liam R. Howlett Cc: "Borislav Petkov (AMD)" Cc: David S. Miller Cc: Geert Uytterhoeven Cc: Guo Ren Cc: Huacai Chen Cc: Ingo Molnar Cc: Johannes Berg Cc: John Paul Adrian Glaubitz Cc: Lorenzo Stoakes Cc: Madhavan Srinivasan Cc: Matt Turner Cc: Max Filippov Cc: Michael Ellerman Cc: Michal Hocko Cc: Michal Simek Cc: Palmer Dabbelt Cc: Richard Weinberger Cc: Russell King Cc: Stafford Horne Cc: Suren Baghdasaryan Cc: Vineet Gupta Cc: Vlastimil Babka Cc: Will Deacon Signed-off-by: Andrew Morton