Alpha arch development list
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Matt Turner <mattst88@gmail.com>,
	Magnus Lindholm <linmag7@gmail.com>,
	Sasha Levin <sashal@kernel.org>,
	richard.henderson@linaro.org, linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.18-5.10] alpha: run the remote RTC access in a worker, not an IPI callback
Date: Mon, 19 Oct 2026 09:52:46 -0400	[thread overview]
Message-ID: <20261019135441.1420968-475-sashal@kernel.org> (raw)
In-Reply-To: <20261019135441.1420968-1-sashal@kernel.org>

From: Matt Turner <mattst88@gmail.com>

[ Upstream commit 6f45effbd74012f1715584ba51abaa3196a47c08 ]

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:
  [<fffffc000102ebb0>] dump_stack+0x28/0x44
  [<fffffc000110efcc>] __lock_acquire+0xb0c/0x1060
  [<fffffc000110f5f0>] lock_acquire.part.0+0xd0/0x300
  [...]
  [<fffffc0001b0d834>] mc146818_set_time+0x74/0x450
  [<fffffc0001f090cc>] _raw_spin_lock_irqsave+0x7c/0xc0
  [<fffffc0001042f90>] do_remote_set+0x90/0xc0
  [<fffffc000119c1a4>] __flush_smp_call_function_queue+0x314/0x5c0
  [<fffffc000119c474>] generic_smp_call_function_single_interrupt+0x24/0x40
  [<fffffc000103d984>] handle_ipi+0xa4/0x230
  [<fffffc0001037044>] 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 <mattst88@gmail.com>
Reviewed-by: Magnus Lindholm <linmag7@gmail.com>
Link: https://lore.kernel.org/r/20260810202835.3592833-1-mattst88@gmail.com
Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Local tree is **6.12.111** (`pending-6.12`). The Marvel remote-RTC IPI
path is in this checkout, `work_on_cpu()` is available, and the patch
applies cleanly. This is a real interrupt-context bug, not a feature.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

**Step 1.1: PARSE THE SUBJECT LINE**

Record: **[alpha]** **[run]** — Marvel CMOS access that today runs in an
IPI callback should run in a worker on the boot CPU instead.

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**

Record:
- **Reviewed-by:** Magnus Lindholm `<linmag7@gmail.com>` (Alpha co-
  maintainer)
- **Link:** `https://lore.kernel.org/r/20260810202835.3592833-1-
  mattst88@gmail.com`
- **Signed-off-by:** Matt Turner `<mattst88@gmail.com>` (Alpha
  maintainer, author)
- **Signed-off-by:** Magnus Lindholm `<linmag7@gmail.com>` (maintainer
  merge)
- No **Fixes:** tag (expected)
- No **Cc: stable** on this committed revision (expected; not used as a
  negative)
- No **Reported-by:** / **Tested-by:** tags in the commit itself; the
  body reports hardware testing by the author
- Ignore pipeline markers (**Upstream commit**, Sasha Levin SOB) per
  instructions

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**

Record:
- **Bug:** On Marvel, CMOS is only reachable from the boot CPU.
  `remote_read_time()` / `remote_set_time()` bounce via
  `smp_call_function_single()`. That callback runs in **hardirq**.
- **Read path:** `alpha_rtc_read_time()` → `mc146818_get_time(tm, 10)` →
  `mc146818_avoid_UIP()` can drop `rtc_lock` and `udelay(100us)` in a
  loop for up to **10 ms**.
- **Write path:** `mc146818_set_time()` takes `rtc_lock` (`spinlock_t`).
  Lockdep reports **Invalid wait context** (`{3:3}` lock in `{2:2}`
  hardirq) on `7.2.0-rc1` when a non-boot CPU sets the clock. Stack:
  `do_remote_set` → `__flush_smp_call_function_queue` → `handle_ipi` →
  `do_entInt`.
- **Symptom:** lockdep BUG on RTC set from a non-boot CPU; boot CPU can
  spin up to 10 ms in IPI while the requester busy-waits in
  `smp_call_function_single()`.
- **Fix:** RTC class ops already run in process context; use
  `work_on_cpu(boot_cpuid, ...)`. Alpha has no CPU hotplug, so the boot
  CPU cannot go offline under the work.
- **Tested:** AlphaServer ES47 (Marvel/EV7); `hwclock` read/write pinned
  to a non-boot CPU, twenty times, no splat.

**Step 1.4: DETECT HIDDEN BUG FIXES**

Record: Not hidden. Explicit interrupt-context / lockdep bug fix. Not
cleanup-only.

===============================================================
PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================

**Step 2.1: INVENTORY THE CHANGES**

Record:
- **File:** `arch/alpha/kernel/rtc.c` only (**+12 / −25**, net −13)
- **Functions:** `do_remote_read`, `remote_read_time`, `do_remote_set`,
  `remote_set_time`
- **Scope:** single-file surgical fix under `HAVE_REMOTE_RTC`
  (`CONFIG_SMP && (CONFIG_ALPHA_GENERIC || CONFIG_ALPHA_MARVEL)`)

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**

Record:
- **Before:** non-boot CPU packs `tm` into `union remote_data`, calls
  `smp_call_function_single(boot_cpuid, do_remote_*, &x, 1)` (wait=1).
  Callback in hardirq writes `x.retval`.
- **After:** `return work_on_cpu(boot_cpuid, do_remote_*, tm)`.
  Callbacks are `long (*)(void *)` and return
  `alpha_rtc_{read,set}_time()` directly. Boot-CPU fast path unchanged.
- **Path:** userspace RTC read/set (`hwclock`, sysfs, `/dev/rtc`) from a
  non-boot CPU on Marvel.

**Step 2.3: IDENTIFY THE BUG MECHANISM**

Record:
- **Category:** interrupt-context abuse / invalid locking context (plus
  hardirq latency).
- **Mechanism:** IPI hardirq took `spinlock_t rtc_lock` and could
  `udelay()` up to 10 ms. Process-context worker can take `spinlock_t`
  and sleep/delay legally.
- Not a leak, UAF, or new API.

**Step 2.4: ASSESS THE FIX QUALITY**

Record:
- Obviously correct: same CMOS work, different execution context.
- Minimal; removes the `union remote_data` marshalling that IPI wait
  required.
- **Regression risk: low.** `work_on_cpu()` sleeps; RTC ops already run
  under `rtc->ops_lock` (mutex) in `drivers/rtc/interface.c`. Alpha has
  no hotplug, so `work_on_cpu()` (not `_safe`) is the right helper.
  `work_on_cpu_key()` in this tree uses on-stack work; it does not
  return `-ENOMEM`.
- Pre-existing `smp_processor_id() != boot_cpuid` race vs migration
  exists in both old and new code; not introduced here.
- Patch 2/2 in the series (IPL 7 `trace_hardirqs_off` annotation) is
  independent; this patch does not need it.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

**Step 3.1: BLAME THE CHANGED LINES**

Record: IPI marshalling is from **`85d0b3a573d8b`** (“alpha: Reorganize
rtc handling”, Richard Henderson, 2013, **v3.13-rc1**). Present for the
entire life of this LTS series.

**Step 3.2: FOLLOW THE FIXES: TAG**

Record: No `Fixes:` tag. The IPI design has been wrong relative to
`mc146818_*` locking/polling since that 2013 code; the 10 ms bound is
from **`120931db07b49`** (“rtc: Add support for configuring the UIP
timeout for RTC reads”, **v6.8-rc1**), which **is** an ancestor of this
HEAD.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**

Record: Recent `arch/alpha/kernel/rtc.c` history is RTC-core API updates
(`mc146818_get_time()` return check, UIP timeout,
`devm_rtc_allocate_device`). No competing rewrite of the remote path.
Standalone vs later RTC core, not part of a required multi-patch RTC
series.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**

Record: Matt Turner is an Alpha maintainer (commits across
`arch/alpha/`, including Marvel IRQ fixes). Magnus Lindholm is also
active on Alpha (memory compaction, etc.) and reviewed this.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**

Record: Needs `work_on_cpu()` (`include/linux/workqueue.h` /
`kernel/workqueue.c`) — present. Needs `alpha_rtc_{read,set}_time` +
`HAVE_REMOTE_RTC` — present. No new helpers. **Applies standalone.**
Series patch 2/2 is a separate irqflags/lockdep issue in `do_entInt()`.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**

Record:
- `b4 dig -c <sha>` could not run: this commit is **not** in the local
  object database.
- `b4 mbox 20260810202835.3592833-1-mattst88@gmail.com` saved a
  **4-message** thread.
- Lore HTTP fetch returned 403; mbox contents were used instead.
- **This is patch 1/2** (v2-style rewrite). An earlier May 2026 patch
  (“Use work_on_cpu() for cross-CPU RTC access”) ignored
  `work_on_cpu()`’s return value; review asked to return it directly.
  The committed diff does that.
- Magnus: “The change looks good to me.” Built/booted on AlphaServer
  ES40 (does not hit Marvel remote-RTC). **Reviewed-by** granted. No
  NAK.
- No reviewer asked for `Cc: stable` on this revision. The May posting
  mentioned stable; that is author intent on an earlier revision, not
  used as the decision.

**Step 4.2: CHECK WHO REVIEWED THE PATCH**

Record: To `linux-alpha@`; Cc Richard Henderson, Magnus Lindholm, LKML.
Reviewed by Magnus (Alpha). Author is Alpha maintainer.

**Step 4.3: SEARCH FOR THE BUG REPORT**

Record: Author-found on ES47 with lockdep (`7.2.0-rc1`). Not syzbot.
Concrete trigger: `hwclock` on a non-boot CPU. Same class of access any
userspace RTC client can perform.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**

Record: 2-patch Alpha lockdep series. **1/2 = this RTC IPI fix (self-
contained). 2/2 = IPL 7 annotation in `irq_alpha.c` (not a
prerequisite).**

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**

Record: No stable@ thread found for this subject (lore.kernel.org 403;
web search showed the LKML/linux-alpha thread only). No known NAK
against backporting.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

**Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF**

Record: `do_remote_read`, `remote_read_time`, `do_remote_set`,
`remote_set_time`. Callees: `alpha_rtc_read_time` / `alpha_rtc_set_time`
→ `mc146818_get_time` / `mc146818_set_time`.

**Step 5.2: TRACE CALLERS**

Record: Only hooked as `remote_rtc_ops.{read,set}_time` when
`alpha_mv.rtc_boot_cpu_only` (set in `arch/alpha/kernel/sys_marvel.c`).
Core RTC calls them from `rtc_read_time()` / `rtc_set_time()` in
`drivers/rtc/interface.c` after
`mutex_lock_interruptible(&rtc->ops_lock)` — **process context**,
userspace-reachable (`hwclock`, sysfs, `/dev/rtc`).

**Step 5.3: TRACE CALLEES**

Record: `mc146818_avoid_UIP()` loops with `spin_lock_irqsave(&rtc_lock)`
and `udelay(UIP_RECHECK_DELAY)` (100 µs), timeout 10 ms from
`alpha_rtc_read_time()`. `mc146818_set_time()` uses
`spin_lock_irqsave(&rtc_lock, flags)` (verified around the CMOS write
setup). `rtc_lock` is `DEFINE_SPINLOCK(rtc_lock)` in
`arch/alpha/kernel/time.c`.

**Step 5.4: FOLLOW THE CALL CHAIN**

Record: Userspace ioctl/sysfs → `rtc_{read,set}_time` (mutex) →
`remote_*` → (old) IPI on boot CPU / (new) `work_on_cpu`. **Reachable
from unprivileged or time-admin userspace** depending on `/dev/rtc`
permissions; `hwclock` is the documented trigger. Not an obscure init-
only path.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**

Record: Other arches use `work_on_cpu()` for CPU-local work that cannot
run in IPI (`arch/x86/kernel/apm_32.c`, cpufreq, PCI probe). No other
Alpha IPI+RTC site. No duplicate of this bug in-tree.

===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**

Record: **Yes.** `arch/alpha/kernel/rtc.c` still uses
`smp_call_function_single` for remote read/set (lines 165–194 in this
checkout). Kernel **6.12.111**. Bug introduced **v3.13**; UIP 10 ms
timeout in this file since **v6.8**.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**

Record: **`git apply --check` succeeded** on this tree (12 insertions,
25 deletions). Surrounding RTC file matches the hunks. Include of
`<linux/workqueue.h>` is appropriate; `work_on_cpu()` macro exists under
`CONFIG_SMP`.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**

Record: `git log --grep='remote RTC' -- arch/alpha/` empty. No earlier
work_on_cpu conversion. **Not already fixed.**

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**

Record: **arch/alpha RTC** (Marvel SMP CMOS). Criticality:
**PERIPHERAL** (Alpha Marvel only), but RTC time get/set is user-visible
and used at boot (`hctosys`) and by `hwclock`. Wrong context can stall
the **boot CPU** in hardirq.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**

Record: Alpha is low-churn but still receiving correctness fixes in this
tree (Marvel IRQ, FPCR, PCI mmap). Mature platform; this IPI scheme is
old, not new experimental code.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

**Step 8.1: DETERMINE WHO IS AFFECTED**

Record: **Platform-specific:** SMP Alpha Marvel (or `ALPHA_GENERIC` on
Marvel hardware) with `rtc_boot_cpu_only`. Not x86/arm. Population is
small but real (ES47 testers).

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**

Record: RTC read or set from a **non-boot CPU**. Common for `hwclock` /
systemd time if the process is not pinned to CPU0. Unprivileged trigger
depends on device node policy; typically `hwclock` is admin. Timing:
every such access, not a rare race (the IPI path is deterministic).

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**

Record:
- **This 6.12 tree, default configs:** Alpha does **not** select
  `HAVE_PREEMPT_RT`. `PROVE_RAW_LOCK_NESTING` is **default n**, so
  `LD_WAIT_CONFIG == LD_WAIT_SPIN` and the exact `{3:3}` vs `{2:2}`
  splat needs that debug option (as on the 7.2-rc1 report).
- **Always on this tree:** boot CPU IPI handler can **poll/udelay up to
  10 ms** in hardirq; requester busy-waits. That is illegal/unwanted in
  interrupt context (IRQ latency on the boot CPU, nested IRQ mess after
  `spin_unlock_irqrestore` inside the callback).
- **With lockdep + `PROVE_RAW_LOCK_NESTING`:** lockdep BUG on set-time
  (documented stack).
- Severity for this tree: **HIGH** for the interrupt-context/latency bug
  on Marvel SMP; **not** a universal panic on a stock distro defconfig
  without lockdep. Still a real correctness bug, not cosmetic.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**

Record:
- **Benefit:** Marvel SMP users stop running CMOS poll/lock in IPI;
  lockdep-enabled kernels stop the wait-context BUG; `hwclock` from a
  secondary CPU is safe.
- **Risk:** very low — ~12 lines, process-context-only, no API change,
  applies cleanly, hardware-tested.
- **Ratio:** favorable. Niche hardware is not a reason to leave a
  hardirq-delay/lockdep bug in an LTS tree that still ships Alpha.

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

**Step 9.1: COMPILE THE EVIDENCE**

**FOR backporting:**
- Real bug: IPI hardirq does `udelay` + `spinlock_t rtc_lock`.
- Buggy code is in **this** 6.12 tree (since v3.13).
- Small, obviously correct, maintainer-authored and reviewed.
- Tested on ES47; Magnus reviewed.
- `work_on_cpu()` exists; no hotplug on Alpha.
- Applies cleanly (`git apply --check` exit 0).
- Userspace-reachable (`hwclock`).
- Independent of series patch 2/2.

**AGAINST:**
- Only Marvel SMP Alpha.
- Stock 6.12 without `PROVE_RAW_LOCK_NESTING` may not print the lockdep
  splat; production impact is primarily **up to 10 ms boot-CPU hardirq
  stall**, not a guaranteed oops.
- No `Fixes:` tag (not a negative per rules).

**UNRESOLVED:** Could not HTTP-fetch lore.kernel.org (403); thread
recovered via `b4 mbox`. Could not `b4 dig -c` a SHA that is not in this
repo.

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**

1. Obviously correct and tested? **PASS** — ES47 `hwclock` ×20; Magnus
   Reviewed-by.
2. Fixes a real bug that affects users? **PASS** — Marvel SMP RTC from a
   non-boot CPU.
3. Important issue? **PASS** — hardirq polling/locking is a serious
   context bug (lockdep BUG under prove-locking; IRQ latency otherwise).
   Not a style cleanup.
4. Small and contained? **PASS** — one file, −13 net lines.
5. No new features or APIs? **PASS** — context change only.
6. Can apply to the local tree? **PASS** — `git apply --check`
   succeeded; prerequisites present.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**

Record: Not a device-ID/quirk/DT/build/docs exception. Ordinary small
arch bugfix.

**Step 9.4: MAKE YOUR DECISION**

Backport. The IPI callback is the wrong context for
`mc146818_get_time()`/`mc146818_set_time()` in this 6.12 tree, the
replacement is the existing `work_on_cpu()` helper, and the change is
tiny and already shown to apply.

===============================================================
What the commit solves for stable users
===============================================================

On Marvel, CMOS must run on the boot CPU. This tree still bounces that
work with `smp_call_function_single()`, so `mc146818_avoid_UIP()` can
spin in **hardirq for up to 10 ms** and `mc146818_set_time()` takes
`rtc_lock` in that IPI. `work_on_cpu(boot_cpuid, ...)` keeps the same
CMOS access but in a worker, which matches how RTC class ops are already
invoked (mutex, process context). Alpha has no CPU hotplug, so the boot
CPU stays online for the work.

It meets stable rules: real bug, small, no new API, clean apply, tested.
Risk is low relative to leaving interrupt-context RTC access in 6.12.

===============================================================
Verification
===============================================================

- **[Phase 1]** Subject/tags parsed from the candidate message;
  Reviewed-by Magnus; Link message-id
  `20260810202835.3592833-1-mattst88@gmail.com`; no Fixes; hardware test
  described in the body.
- **[Phase 2]** Diff is only `arch/alpha/kernel/rtc.c`; IPI →
  `work_on_cpu`; union marshalling removed.
- **[Phase 2]** Local `rtc.c` still has `smp_call_function_single` in
  `remote_read_time`/`remote_set_time`.
- **[Phase 2]** `mc146818_avoid_UIP()` in `drivers/rtc/rtc-
  mc146818-lib.c` confirmed: `spin_lock_irqsave` + `udelay(100)` loop;
  `alpha_rtc_read_time()` passes timeout **10**.
- **[Phase 2]** `mc146818_set_time()` takes `rtc_lock`;
  `DEFINE_SPINLOCK(rtc_lock)` in `arch/alpha/kernel/time.c`.
- **[Phase 2]** `rtc_read_time`/`rtc_set_time` take `rtc->ops_lock`
  mutex (`drivers/rtc/interface.c`) — process context.
- **[Phase 3]** `git blame` on remote RTC: `85d0b3a573d8b` (v3.13-rc1);
  `git merge-base --is-ancestor 85d0b3a573d8b HEAD` true.
- **[Phase 3]** Timeout commit `120931db07b49` is ancestor of HEAD
  (v6.8-rc1).
- **[Phase 3]** No HOTPLUG in `arch/alpha/Kconfig`; `work_on_cpu()`
  present in `include/linux/workqueue.h` / `kernel/workqueue.c` (on-
  stack work, no `-ENOMEM`).
- **[Phase 3]** `rtc_boot_cpu_only = 1` only in
  `arch/alpha/kernel/sys_marvel.c`.
- **[Phase 4]** `b4 mbox` thread: 4 messages; patch 1/2 this fix, patch
  2/2 independent; Magnus Reviewed-by; no NAK.
- **[Phase 4]** Earlier May patch had return-value review; committed
  version returns `work_on_cpu()`.
- **[Phase 4]** lore.kernel.org WebFetch: 403; contents recovered from
  mbox.
- **[Phase 5]** Callers limited to `remote_rtc_ops`; userspace RTC path.
- **[Phase 6]** `git describe HEAD` → `p-6.12-3-gc504cf0baa3d8`; `make
  kernelversion` → **6.12.111**.
- **[Phase 6]** `git apply --check` on extracted mbox diff: **exit 0**.
- **[Phase 6]** Fix not already in this tree (`git log --grep='remote
  RTC' -- arch/alpha/` empty).
- **[Phase 7]** Alpha Marvel RTC; peripheral but user-facing.
- **[Phase 8]** `PROVE_RAW_LOCK_NESTING` default n in this tree; Alpha
  has no `HAVE_PREEMPT_RT`. Lockdep splat needs that debug option; 10 ms
  IPI `udelay` does not.
- **UNVERIFIED:** Exact mainline SHA (not in this object db). Whether
  distro 6.12 Alpha configs enable `PROVE_RAW_LOCK_NESTING`.

The patch is a small, tested context fix for a bug that exists in this
tree and applies without prerequisites.

**YES**

 arch/alpha/kernel/rtc.c | 37 ++++++++++++-------------------------
 1 file changed, 12 insertions(+), 25 deletions(-)

diff --git a/arch/alpha/kernel/rtc.c b/arch/alpha/kernel/rtc.c
index cfdf90bc8b3f8..9e7d714ef6f85 100644
--- a/arch/alpha/kernel/rtc.c
+++ b/arch/alpha/kernel/rtc.c
@@ -15,6 +15,7 @@
 #include <linux/bcd.h>
 #include <linux/rtc.h>
 #include <linux/platform_device.h>
+#include <linux/workqueue.h>
 
 #include "proto.h"
 
@@ -142,54 +143,40 @@ static const struct rtc_class_ops alpha_rtc_ops = {
 };
 
 /*
- * Similarly, except do the actual CMOS access on the boot cpu only.
- * This requires marshalling the data across an interprocessor call.
+ * Similarly, except do the actual CMOS access on the boot cpu only.  The
+ * access polls for the RTC update cycle and takes rtc_lock, so run it in a
+ * worker on that cpu rather than from an interprocessor interrupt.
  */
 
 #if defined(CONFIG_SMP) && \
     (defined(CONFIG_ALPHA_GENERIC) || defined(CONFIG_ALPHA_MARVEL))
 # define HAVE_REMOTE_RTC 1
 
-union remote_data {
-	struct rtc_time *tm;
-	long retval;
-};
-
-static void
+static long
 do_remote_read(void *data)
 {
-	union remote_data *x = data;
-	x->retval = alpha_rtc_read_time(NULL, x->tm);
+	return alpha_rtc_read_time(NULL, data);
 }
 
 static int
 remote_read_time(struct device *dev, struct rtc_time *tm)
 {
-	union remote_data x;
-	if (smp_processor_id() != boot_cpuid) {
-		x.tm = tm;
-		smp_call_function_single(boot_cpuid, do_remote_read, &x, 1);
-		return x.retval;
-	}
+	if (smp_processor_id() != boot_cpuid)
+		return work_on_cpu(boot_cpuid, do_remote_read, tm);
 	return alpha_rtc_read_time(NULL, tm);
 }
 
-static void
+static long
 do_remote_set(void *data)
 {
-	union remote_data *x = data;
-	x->retval = alpha_rtc_set_time(NULL, x->tm);
+	return alpha_rtc_set_time(NULL, data);
 }
 
 static int
 remote_set_time(struct device *dev, struct rtc_time *tm)
 {
-	union remote_data x;
-	if (smp_processor_id() != boot_cpuid) {
-		x.tm = tm;
-		smp_call_function_single(boot_cpuid, do_remote_set, &x, 1);
-		return x.retval;
-	}
+	if (smp_processor_id() != boot_cpuid)
+		return work_on_cpu(boot_cpuid, do_remote_set, tm);
 	return alpha_rtc_set_time(NULL, tm);
 }
 
-- 
2.53.0


           reply	other threads:[~2026-10-19 14:05 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20261019135441.1420968-1-sashal@kernel.org>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261019135441.1420968-475-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=linmag7@gmail.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mattst88@gmail.com \
    --cc=patches@lists.linux.dev \
    --cc=richard.henderson@linaro.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox