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

Merge tag 'alpha-for-v7.3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/lindholm/alpha

2026-08-19T02:33:32+00:00

Pull alpha updates from Magnus Lindholm:
 "This contains two fixes for Alpha floating-point exception handling,
  two clang-related fixes, the preparatory changes from the
  generic-entry series, an interrupt-entry lockdep fix, two Marvel/EV7
  IRQ fixes, an RTC fix, and one header cleanup.

  The generic-entry preparation adds regset-based ptrace and core dumps,
  ARCH_STACKWALK and lockdep hardirq-state tracking. These changes are
  useful independently and enable previously missing debugging
  facilities on Alpha.

  The final patch switching Alpha to GENERIC_ENTRY is intentionally not
  included in this pull request. I am deferring that change to allow
  further testing and to reduce the risk of conflicts with ongoing
  entry-path work elsewhere in the kernel"

* tag 'alpha-for-v7.3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/lindholm/alpha:
  alpha: read $gp and $sp explicitly for clang
  alpha: pass -Wa,-mev6 only when using GNU as
  alpha: annotate hardirqs-off on IPL 7 interrupt entry
  alpha: run the remote RTC access in a worker, not an IPI callback
  alpha: don't leak hardware-fabricated FP exception bits to user space
  alpha: fix ieee_swcr_to_fpcr setting FPCR_DNOD unconditionally
  alpha: enable lockdep hardirq state tracking
  alpha: use raw spinlocks for low-level platform locks
  alpha: provide ftrace return address support for lockdep
  alpha: make irqflags helpers operate on IPL state
  alpha: add ARCH_STACKWALK-based stacktrace support
  alpha: enable regset-based ptrace and core dumps
  alpha: marvel: Fix lock ordering in init_io7_irqs()
  alpha: marvel: Fix irq_set_status_flags to use correct IRQ number
  alpha: remove unnecessary architecture-specific

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()
  ...

alpha: read $gp and $sp explicitly for clang

2026-08-16T14:00:00+00:00

clang honors a local `register unsigned long x __asm__("$N")` variable
only where it appears as an inline-asm operand; merely reading it does
not produce the contents of that register.  So trap_init() passed an
undefined global pointer to PAL_wrkgp, and load_PCB() stored an undefined
stack pointer into the PCB that swpctx then loaded.  Either one wedges an
early boot.

Read the registers explicitly instead: an inline mov for $gp in
trap_init(), and the file-scope current_stack_pointer for $sp in
load_PCB().  A file-scope register-asm variable is the form clang does
support.

Signed-off-by: Matt Turner 
Reviewed-by: Maciej W. Rozycki 
Reviewed-by: Magnus Lindholm 
Tested-by: Magnus Lindholm 
Link: https://lore.kernel.org/r/20260803-alpha-clang-v1-2-1c4ba5ba7a64@gmail.com
Signed-off-by: Magnus Lindholm

alpha: annotate hardirqs-off on IPL 7 interrupt entry

2026-08-11T21:23:48+00:00

do_entInt() opens with local_irq_disable(), which with
CONFIG_TRACE_IRQFLAGS only calls trace_hardirqs_off() if interrupts were
not already off:

	#define local_irq_disable()				\
		do {						\
			bool was_disabled = raw_irqs_disabled();\
			raw_local_irq_disable();		\
			if (!was_disabled)			\
				trace_hardirqs_off();		\
		} while (0)

On alpha raw_irqs_disabled() is (rdps() & 7) == IPL_MAX, i.e. IPL 7.
PALcode raises PS.IPL to the level of the interrupt before entInt runs,
so for an IPL 7 entry - a processor machine check (vector 0x660) or a
system event (vector 0x680), both IPL_MCHECK == IPL_MAX - the gate is
already true and the annotation is skipped.  lockdep keeps whatever
hardirq state the interrupted context had.  If that context had
interrupts enabled, lockdep believes they are still enabled for the
duration of the handler, and every lockdep_assert_irqs_disabled() in the
interrupt path fires:

  WARNING: kernel/context_tracking.c:346 at ct_irq_enter+0xc4/0xd0, CPU#0: swapper/0/0
  [...]
  [] ct_irq_enter+0xc4/0xd0
  [] irq_enter+0x20/0x50
  [] do_entInt+0x1dc/0x2e0
  [] ret_from_exception+0x0/0x10

  irq event stamp: 735356346
  hardirqs last  enabled at (735356346): trace_hardirqs_on+0x68/0x220
  hardirqs last disabled at (735356345): do_idle+0xf0/0x270

The stamps show the problem directly: the most recent event is the
enable from the interrupted idle loop, and do_entInt() recorded no
disable at all.  ct_irq_exit() warns the same way on the way out.

Ordinary device interrupts arrive at IPL 3-5 and IPIs and performance
counter interrupts at IPL 6, so was_disabled is false for them and the
annotation happens normally.  Only the two IPL 7 vectors are affected,
which is why this needs an environmental event to show up.

Take the hardware IPL out of the decision and drive the annotation from
lockdep's own state instead.

This corrects the annotation only.  An IPL 7 event can also interrupt a
region that has legitimately disabled interrupts, where irq_enter() and
irq_exit() are not the right primitives and NMI semantics are needed;
that is a larger change and is left alone here.

Tested on an AlphaServer ES47 (Marvel/EV7) by injecting system events
through the system management path: fifteen injections, idle and under
load, with no splat.  The same injection on a freshly booted kernel
without this change reproduces both warnings.

Signed-off-by: Matt Turner 
Reviewed-by: Magnus Lindholm 
Tested-by: Magnus Lindholm 
Link: https://lore.kernel.org/r/20260810202835.3592833-2-mattst88@gmail.com
Signed-off-by: Magnus Lindholm

alpha: run the remote RTC access in a worker, not an IPI callback

2026-08-11T21:23:47+00:00

On Marvel the CMOS clock is only reachable from the boot cpu, so
remote_read_time() and remote_set_time() bounce the access there with
smp_call_function_single(), whose callback runs in hard interrupt
context.

alpha_rtc_read_time() calls mc146818_get_time() with a 10 ms timeout.
That waits out the RTC update cycle in mc146818_avoid_UIP(), which drops
rtc_lock and udelay()s 100 us at a time until the update completes or
the timeout expires:

	for (i = 0; UIP_RECHECK_LOOPS_MS(i) < timeout; i++) {
		spin_lock_irqsave(&rtc_lock, flags);
		...
		if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) {
			spin_unlock_irqrestore(&rtc_lock, flags);
			udelay(UIP_RECHECK_DELAY);
			continue;
		}

So a clock read from a non-boot cpu can spin for up to 10 ms in hard
interrupt context on the boot cpu, while the cpu that sent the request
spins in smp_call_function_single() waiting for it to finish.

mc146818_set_time() does not poll, but it takes rtc_lock too, and
rtc_lock is a spinlock_t.  Only raw spinlocks may be taken in hard
interrupt context, so lockdep reports the write path as soon as a
non-boot cpu sets the clock:

  [ BUG: Invalid wait context ]
  -----------------------------
  swapper/0/0 is trying to lock:
  fffffc0003690470 (rtc_lock){....}-{3:3}, at: mc146818_set_time+0x74/0x450
  other info that might help us debug this:
  context-{2:2}
  no locks held by swapper/0/0.
  stack backtrace:
  CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc1 #1 NONE
  Trace:
  [] dump_stack+0x28/0x44
  [] __lock_acquire+0xb0c/0x1060
  [] lock_acquire.part.0+0xd0/0x300
  [...]
  [] mc146818_set_time+0x74/0x450
  [] _raw_spin_lock_irqsave+0x7c/0xc0
  [] do_remote_set+0x90/0xc0
  [] __flush_smp_call_function_queue+0x314/0x5c0
  [] generic_smp_call_function_single_interrupt+0x24/0x40
  [] handle_ipi+0xa4/0x230
  [] do_entInt+0x1a4/0x2e0

The rtc class ops are always called from process context, so there is no
reason to run the access from an interrupt at all.  Use work_on_cpu() to
run it in a worker on the boot cpu.  Alpha does not support cpu hotplug,
so the boot cpu cannot go offline while the work is pending.

Tested on an AlphaServer ES47 (Marvel/EV7): hwclock read and write
pinned to a non-boot cpu, twenty times, with no splat.

Signed-off-by: Matt Turner 
Reviewed-by: Magnus Lindholm 
Link: https://lore.kernel.org/r/20260810202835.3592833-1-mattst88@gmail.com
Signed-off-by: Magnus Lindholm

alpha: don't leak hardware-fabricated FP exception bits to user space

2026-08-11T21:07:54+00:00

On EV6 and later the hardware records exception status bits in the FPCR
before delivering a software completion trap, and those bits can be wrong
for the instruction that trapped.  Converting a double that is exactly
representable as a subnormal float sets FPCR_UNF even though the result
is exact, and an underflow trap additionally sets FPCR_INE even when the
emulated operation turns out to be exact.

alpha_fp_emul() only wrote the FPCR when soft-fp raised an exception, so
whenever it determined that the instruction was exact the fabricated bits
stayed in the FPCR and were reported to user space by fetestexcept().

Pass the exception summary register down from do_entArith() so the
handler can tell which exceptions the hardware attributed to the trapping
instruction, and always write the FPCR.  Clear the exceptions that the
trap reported but that soft-fp did not raise.  EXC_SUM reports only the
underflow or overflow when the hardware also set INE, so treat INE as a
candidate in that case, and treat a trap with no reported exception as a
denormal operand trap, for which the hardware can fabricate INE and UNF
as well.  Bits that software has already confirmed in ieee_state belong
to this or an earlier instruction and are never cleared.

The imprecise path passes no summary.  There the trap was taken somewhere
in the trap shadow, so EXC_SUM is not attribution for the instruction
being re-executed -- and only EV6, which traps precisely and so never
takes that path, has fabricated bits to clear.  For the same reason the
clearing is guarded by implver(), matching swcr_update_status().

On an UP1500 (EV68) this takes the glibc math testsuite from 831 failures
to 28, the remainder being unrelated to exception status.

This belongs with the preceding fix to ieee_swcr_to_fpcr(), and should
not be backported without it -- nor it without this.  That fix stops
FPCR_DNOD being set unconditionally, so denormal operand traps start
firing again.  Those traps very often find an exact result, which is
precisely the case where the old code left the FPCR unwritten and the
fabricated bits visible.  Applied alone it would make spurious exception
flags more common, not less.

One case cannot be resolved here: an inexact instruction without the
software completion suffix never traps, so its INE reaches the FPCR
without being recorded anywhere else.  Such a bit is indistinguishable
from an INE the hardware fabricated for a trapping instruction, and is
lost if an underflow or overflow trap with an exact result follows it.
The FPCR is the only record of those instructions and it carries no
attribution.

The bug predates the git history, so there is no commit to reference in a
Fixes tag.

Cc: stable@vger.kernel.org # 5.15+
Signed-off-by: Matt Turner 
Reviewed-by: Magnus Lindholm 
Tested-by: Magnus Lindholm 
Link: https://lore.kernel.org/r/20260803-alpha-fp-exceptions-v1-2-c99d75608e60@gmail.com
Signed-off-by: Magnus Lindholm

arch: hookup fchroot() system call

2026-07-27T15:18:00+00:00

Wire up the fchroot() system call as number 472 on (nearly) all
architectures and sync the mirrored copies of the syscall tables and
the asm-generic unistd.h under tools/.

Link: https://patch.msgid.link/20260724-work-failfs-v2-5-485dabbae185@kernel.org
Signed-off-by: Christian Brauner (Amutable)

alpha: enable lockdep hardirq state tracking

2026-07-19T11:16:26+00:00

Alpha masks interrupts through the PAL IPL state, so lockdep cannot infer
hardirq state transitions from generic code alone. Add explicit
hardirq on/off annotations to the low-level entry and return paths so
lockdep's IRQ state follows the hardware IPL state.

Annotate the PAL IPL transitions and the shared return-to-user/kernel
paths where interrupts become enabled or disabled.  With the preceding
irqflags, raw-lock, sysfs, and ftrace return-address preparations in
place, select LOCKDEP_SUPPORT and TRACE_IRQFLAGS_SUPPORT for Alpha.

This keeps CONFIG_PROVE_LOCKING usable on Alpha instead of disabling
debug_locks due to IRQ-state mismatches.

Reviewed-by: Matt Turner 
Tested-by: Matt Turner 
Signed-off-by: Magnus Lindholm 
Link: https://lore.kernel.org/r/20260706170019.2941459-7-linmag7@gmail.com
Signed-off-by: Magnus Lindholm

alpha: use raw spinlocks for low-level platform locks

2026-07-19T11:16:15+00:00

Some Alpha platform locks are used as low-level hardware serialization
locks in interrupt-controller and chipset access paths. These paths can
run while IRQ state is being changed or while lockdep is tracking that
state, so regular spinlock instrumentation is not appropriate once
lockdep is enabled.

Convert the affected Tsunami and Rawhide platform locks to
raw_spinlock_t. This keeps the locks as simple hardware serialization
locks and avoids lockdep recursion or IRQ-state mismatches when
CONFIG_PROVE_LOCKING is enabled.

This is a preparatory change for enabling lockdep hardirq state tracking
on Alpha.

Reviewed-by: Matt Turner 
Tested-by: Matt Turner 
Signed-off-by: Magnus Lindholm 
Link: https://lore.kernel.org/r/20260706170019.2941459-6-linmag7@gmail.com
Signed-off-by: Magnus Lindholm

alpha: add ARCH_STACKWALK-based stacktrace support

2026-07-19T11:15:54+00:00

Implement arch_stack_walk() for Alpha using a simple kernel
stack scanning walker. Start from regs+1 for current tasks
to skip pt_regs and use pcb.ksp for blocked tasks. Filter
candidates with __kernel_text_address() and stop at stack
bounds via kstack_end().

Enable CONFIG_STACKTRACE_SUPPORT and CONFIG_ARCH_STACKWALK
so generic stacktrace users (dump_stack(), /proc/*/stack,
SysRq backtraces, etc.) work on Alpha.

This provides functional in-kernel stack traces without
requiring frame pointer unwinding.

Reviewed-by: Matt Turner 
Tested-by: Matt Turner 
Signed-off-by: Magnus Lindholm 
Link: https://lore.kernel.org/r/20260706170019.2941459-3-linmag7@gmail.com
Signed-off-by: Magnus Lindholm