linux-stable.git/arch/openrisc/kernel, branch master

Merge tag 'core-entry-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-08-18T22:00:56+00:00

Pull generic entry code updates from Thomas Gleixner:

 - Make syscall user dispatching configurable

   Not all architectures can makes use of syscall user dispatching.
   Allow them to disable the feature completely.

 - Consolidate stack randomization for the generic entry code and the
   architectures using it.

   Stack randomization on syscall entry was sprinkled throughout the
   architecture specific low level entry code and in some cases at the
   wrong points, e.g. before establishing state, which violates the
   non-instrumentable constraints of that code.

   Clean this up by integrating stack randomization into the generic
   entry code helpers so that it is invoked at the earliest possible
   point right after establishing state and converting all generic entry
   code using architecture over.

 - Clean up the syscall number handling in the generic entry code. It
   works correctly for architectures which have a separate return value
   storage in pt_regs, but fails to distinguish the case where user
   space handed in -1 as syscall number from the case where the entry
   code rejects it by returning -1 to the callers. Aside of that the
   return value functionality of those interfaces is not really
   intuitive.

   Fix this by separating the decision to reject a syscall (user
   dispatch, ptrace, seccomp ...) from the potential modification of the
   syscall number through these mechanisms.

   This solves most of the problems for architectures which do not have
   a separate return value storage in pt_regs except for the case where
   a tracepoint has a BPF script or a probe attached which overwrite
   both the syscall number and the return value. But that's a problem
   which cannot be solved in the generic code, that only can be
   addressed by separating the storage model in the affected
   architectures.

* tag 'core-entry-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (23 commits)
  entry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall execution
  entry: Make return type of syscall_trace_enter() bool
  entry: Rework trace_syscall_enter()
  entry: Rework syscall_audit_enter()
  syscall_user_dispatch: Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH
  entry: Fix seccomp bypass after ptrace with TSYNC
  x86/entry: Simplify the syscall number logic
  x86/entry: Get rid of the sys_ni_syscall() indirection
  x86/entry: Make syscall functions static
  ptrace, treewide: Rename ptrace_report_syscall_entry() to ptrace_report_syscall_permit_entry()
  seccomp, treewide: Rename and convert __secure_computing() to return boolean
  entry: Use syscall number instead of rereading it
  entry: Remove syscall_enter_from_user_mode()
  x86/syscall: Use [syscall_]enter_from_user_mode_randomize_stack()
  s390/syscall: Use enter_from_user_mode_randomize_stack()
  riscv/syscall: Use syscall_enter_from_user_mode_randomize_stack()
  powerpc/syscall: Use syscall_enter_from_user_mode_randomize_stack()
  loongarch/syscall: Use syscall_enter_from_user_mode_randomize_stack()
  entry: Provide [syscall_]enter_from_user_mode_randomize_stack()
  randomize_kstack: Provide add_random_kstack_offset_irqsoff()
  ...

openrisc: signal: do not restore privileged SR bits on sigreturn

2026-08-15T06:14:55+00:00

restore_sigcontext() copies the whole supervision register (SR) from the
signal frame and only clears SPR_SR_SM before the value is reloaded into
the hardware SR (through ESR and l.rfe) on the return to user space.  All
other SR bits are left under user control.

An unprivileged task can thus return from a signal handler through a
crafted sigframe that clears SPR_SR_DME.  With the data MMU disabled the
CPU performs no translation or protection on data accesses, so the task
gains read and write access to arbitrary physical memory, a local
privilege escalation.  SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH
and the cache-enable bits are exposed the same way.  The ptrace GPR regset
already refuses any change to SR for exactly this reason.

Restore only the arithmetic flag bits (F, CY, OV) from the signal frame
and take every privileged control bit from the SR the kernel saved on
signal entry.

Verified with qemu-system-or1k -M or1k-sim: before this change an
unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to
physical address 0x03000000 (beyond the kernel's mem=32M); afterwards the
same PoC receives SIGSEGV and physical memory is unchanged.

Fixes: ac689eb7f9d4 ("OpenRISC: Signal handling")
Cc: stable@vger.kernel.org
Signed-off-by: Ali Ahmet Memis 
Signed-off-by: Stafford Horne

ptrace, treewide: Rename ptrace_report_syscall_entry() to ptrace_report_syscall_permit_entry()

2026-07-12T10:38:02+00:00

The return value of that function is boolean and tells the caller whether
to permit the syscall processing or not.

Rename the function so the purpose is clear and make the return type bool.

Signed-off-by: Thomas Gleixner 
Tested-by: Mukesh Kumar Chaurasiya (IBM) 
Reviewed-by: Jinjie Ruan 
Reviewed-by: Radu Rendec 
Reviewed-by: Mukesh Kumar Chaurasiya (IBM) 
Acked-by: Oleg Nesterov 
Acked-by: Magnus Lindholm 
Link: https://patch.msgid.link/20260707190254.280015701@kernel.org

Merge tag 'for-linus' of https://github.com/openrisc/linux

2026-06-21T16:43:59+00:00

Pull OpenRISC updates from Stafford Horne:
 "A few fixes for text patching related code:

   - Update the section of map_page used in text patching. It was
     left with __init when text patching was introduced to OpenRISC

   - Add fix to invalidate remote SMP core i-caches after text is
     patched"

* tag 'for-linus' of https://github.com/openrisc/linux:
  openrisc: Fix jump_label smp syncing
  openrisc: Add full instruction cache invalidate functions
  openrisc: Cache invalidation cleanup
  openrisc: mm: Fix section mismatch between map_page and __set_fixmap

openrisc: Fix jump_label smp syncing

2026-05-23T05:34:49+00:00

The original commit 8c30b0018f9d ("openrisc: Add jump label support")
copies from arm64 and does not properly consider how icache invalidation
on remote cores works in OpenRISC.  On OpenRISC remote icaches need to
be invalidated otherwise static key's may remain state after updating.

Fix SMP cache syncing by:

 1. Properly invalidate remote core icaches on SMP systems by using
    icache_all_inv.  The old code uses kick_all_cpus_sync() which runs a
    no-op IPI function call on remote CPU's which does execute a lot of
    code and flushes many cache lines in the process, but does not flush
    all and it's not correct on OpenRISC.
 2. For architectures that do not have WRITETHROUGH caches be sure
    to flush the dcache after patching.

To test this I first reproduced the issue using a custom test module
[0].  The test confirmed that some icache lines maintained stale
static_key code sequences after calling static_branch_enable().  After
this patch there are no longer jump_label coherency issues.

[0] https://github.com/stffrdhrn/or1k-utils/tree/master/tests/smp_static_key_test

Cc: stable@vger.kernel.org # depends on openrisc: Add icache_all_inv
Fixes: 8c30b0018f9d ("openrisc: Add jump label support")
Signed-off-by: Stafford Horne

openrisc: Add full instruction cache invalidate functions

2026-05-23T05:34:35+00:00

Add functions to invalidate all cache lines which we will use for
static_key patching.

On OpenRISC there is no instruction to invalidate an entire cache so we
loop and invalidate cache lines one by one.  This is not extremely
expensive on OpenRISC as we usually have only a few hundred cache lines.

I considered using the invalidate cache page or range functions.
However, tracking which ranges need invalidation would have been more
expensive than flushing all pages.

Cc: stable@vger.kernel.org
Signed-off-by: Stafford Horne

openrisc: Cache invalidation cleanup

2026-05-23T05:00:52+00:00

When working on new cache invalidation functions I noticed these
cleanups in the cache initialization code.  Remove unused and commented
instructions to avoid confusion.

Signed-off-by: Stafford Horne

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

kbuild: Split .modinfo out from ELF_DETAILS

2026-02-26T18:50:19+00:00

Commit 3e86e4d74c04 ("kbuild: keep .modinfo section in
vmlinux.unstripped") added .modinfo to ELF_DETAILS while removing it
from COMMON_DISCARDS, as it was needed in vmlinux.unstripped and
ELF_DETAILS was present in all architecture specific vmlinux linker
scripts. While this shuffle is fine for vmlinux, ELF_DETAILS and
COMMON_DISCARDS may be used by other linker scripts, such as the s390
and x86 compressed boot images, which may not expect to have a .modinfo
section. In certain circumstances, this could result in a bootloader
failing to load the compressed kernel [1].

Commit ddc6cbef3ef1 ("s390/boot/vmlinux.lds.S: Ensure bzImage ends with
SecureBoot trailer") recently addressed this for the s390 bzImage but
the same bug remains for arm, parisc, and x86. The presence of .modinfo
in the x86 bzImage was the root cause of the issue worked around with
commit d50f21091358 ("kbuild: align modinfo section for Secureboot
Authenticode EDK2 compat"). misc.c in arch/x86/boot/compressed includes
lib/decompress_unzstd.c, which in turn includes lib/xxhash.c and its
MODULE_LICENSE / MODULE_DESCRIPTION macros due to the STATIC definition.

Split .modinfo out from ELF_DETAILS into its own macro and handle it in
all vmlinux linker scripts. Discard .modinfo in the places where it was
previously being discarded from being in COMMON_DISCARDS, as it has
never been necessary in those uses.

Cc: stable@vger.kernel.org
Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped")
Reported-by: Ed W 
Closes: https://lore.kernel.org/587f25e0-a80e-46a5-9f01-87cb40cfa377@wildgooses.com/ [1]
Tested-by: Ed W  # x86_64
Link: https://patch.msgid.link/20260225-separate-modinfo-from-elf-details-v1-1-387ced6baf4b@kernel.org
Signed-off-by: Nathan Chancellor

openrisc: Fix IPIs on simple multicore systems

2026-01-16T16:38:56+00:00

Commit c05671846451 ("openrisc: sleep instead of spin on secondary
wait") fixed OpenRISC SMP Linux for QEMU. However, stability was never
achieved on FPGA development boards.  This is because the above patch
has a step to unmask IPIs on non-boot cpu's but on hardware without
power management, IPIs remain masked.

This meant that IPI's were never actually working on the simple SMP
systems we run on development boards.  The systems booted but stability
was very suspect.

Add the ability to unmask IPI's on the non-boot cores.  This is done by
making the OMPIC IRQs proper percpu IRQs.  We can then use the
enabled_percpu_irq() to unmask IRQ on the non-boot cpus.

Update the or1k PIC driver to use a flow handler that can switch between
percpu and the configured level or edge flow handlers at runtime.
This mechanism is inspired by that done in the J-Core AIC driver.

Signed-off-by: Stafford Horne 
Acked-by: Thomas Gleixner