[PATCH AUTOSEL 6.18-6.12] riscv: panic if IRQ handler stacks cannot be allocated

[PATCH AUTOSEL 6.18-6.12] riscv: panic if IRQ handler stacks cannot be allocated

[Sasha Levin]

From: Osama Abdelkader <osama.abdelkader@gmail.com>

[ Upstream commit 2abd0dba562551d5c27f97ce560684f534c0cf3a ]

init_irq_stacks() and init_irq_scs() may fail when arch_alloc_vmap_stack
or scs_alloc return NULL, call panic() in this case.

Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Link: https://patch.msgid.link/20260404185522.21767-1-osama.abdelkader@gmail.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The branch check finished: `2abd0dba56255` ("riscv: panic if IRQ handler
stacks cannot be allocated") is on `master` and the `-next` integration
branches, but not on the current `v6.18.44` stable tree. That matches
the earlier **YES** backport recommendation — the fix is mainline-only
and still needs to be cherry-picked into 6.18.y.

 arch/riscv/kernel/irq.c | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/arch/riscv/kernel/irq.c b/arch/riscv/kernel/irq.c
index b6af20bc300f5..017d42e778be6 100644
--- a/arch/riscv/kernel/irq.c
+++ b/arch/riscv/kernel/irq.c
@@ -75,28 +75,34 @@ DECLARE_PER_CPU(ulong *, irq_shadow_call_stack_ptr);
 DEFINE_PER_CPU(ulong *, irq_shadow_call_stack_ptr);
 #endif
 
-static void init_irq_scs(void)
+static void __init init_irq_scs(void)
 {
 	int cpu;
+	void *s;
 
 	if (!scs_is_enabled())
 		return;
 
-	for_each_possible_cpu(cpu)
-		per_cpu(irq_shadow_call_stack_ptr, cpu) =
-			scs_alloc(cpu_to_node(cpu));
+	for_each_possible_cpu(cpu) {
+		s = scs_alloc(cpu_to_node(cpu));
+		if (!s)
+			panic("Failed to allocate IRQ shadow call stack resources\n");
+		per_cpu(irq_shadow_call_stack_ptr, cpu) = s;
+	}
 }
 
 DEFINE_PER_CPU(ulong *, irq_stack_ptr);
 
 #ifdef CONFIG_VMAP_STACK
-static void init_irq_stacks(void)
+static void __init init_irq_stacks(void)
 {
 	int cpu;
 	ulong *p;
 
 	for_each_possible_cpu(cpu) {
 		p = arch_alloc_vmap_stack(IRQ_STACK_SIZE, cpu_to_node(cpu));
+		if (!p)
+			panic("Failed to allocate IRQ stack resources\n");
 		per_cpu(irq_stack_ptr, cpu) = p;
 	}
 }
@@ -104,7 +110,7 @@ static void init_irq_stacks(void)
 /* irq stack only needs to be 16 byte aligned - not IRQ_STACK_SIZE aligned. */
 DEFINE_PER_CPU_ALIGNED(ulong [IRQ_STACK_SIZE/sizeof(ulong)], irq_stack);
 
-static void init_irq_stacks(void)
+static void __init init_irq_stacks(void)
 {
 	int cpu;
 
@@ -129,8 +135,8 @@ void do_softirq_own_stack(void)
 #endif /* CONFIG_SOFTIRQ_ON_OWN_STACK */
 
 #else
-static void init_irq_scs(void) {}
-static void init_irq_stacks(void) {}
+static void __init init_irq_scs(void) {}
+static void __init init_irq_stacks(void) {}
 #endif /* CONFIG_IRQ_STACKS */
 
 int arch_show_interrupts(struct seq_file *p, int prec)
-- 
2.53.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH AUTOSEL 6.18] riscv: kexec_file: Constrain segment placement to direct map

[Sasha Levin]

From: Han Gao <gaohan@iscas.ac.cn>

[ Upstream commit b67a1ee0db0094c6cc158b087be6c334ad881a41 ]

When kexec_file_load places segments with buf_max=ULONG_MAX and
top_down=true, they land at the highest available physical addresses.
On RISC-V the size of the linear mapping is determined by the active
VM mode: SV39 caps the direct map at roughly 128GB, while SV48/SV57
extend the range substantially further. When the installed physical
memory exceeds the direct map size of the active mode, top-down
placement puts DTB/initrd at physical addresses outside the linearly
mapped region. The kexec'd kernel cannot reach them during early
boot, triggering a page fault at memcmp in start_kernel.

Fix by constraining buf_max to PFN_PHYS(max_low_pfn), which reflects
the runtime direct map boundary for the active VM mode (SV39/SV48/
SV57). This keeps all kexec segments within the linearly mapped
region while preserving the upstream top_down allocation strategy.

Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Link: https://patch.msgid.link/20260519170641.123517-1-gaohan@iscas.ac.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

**Step 1.1 — Subject line**

Record: `[riscv: kexec_file]` `[Constrain]` — Constrain kexec_file
segment placement to stay within the RISC-V direct (linear) map.

**Step 1.2 — Tags**

Record:
- `Signed-off-by: Han Gao <gaohan@iscas.ac.cn>` (author)
- `Link:
  https://patch.msgid.link/20260519170641.123517-1-gaohan@iscas.ac.cn`
- `Signed-off-by: Paul Walmsley <pjw@kernel.org>` (RISC-V maintainer)
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Cc:
  stable@vger.kernel.org`
- Notable: maintainer ack; no syzbot or user bug report tags

**Step 1.3 — Body analysis**

Record:
- **Bug:** With `buf_max=ULONG_MAX` and `top_down=true`, kexec_file
  segments (DTB, initrd, purgatory, elfcorehdr) are placed at the
  highest physical addresses. On RISC-V, the linear map size depends on
  the active VM mode (SV39 ≈ 128 GB; SV48/SV57 larger). When installed
  RAM exceeds the direct-map limit, segments land outside the linearly
  mapped region.
- **Symptom:** The kexec'd kernel page-faults in `memcmp` during
  `start_kernel` because it cannot access initrd/DTB.
- **Root cause:** Top-down placement is unconstrained by the direct-map
  boundary.
- **Fix approach:** Set `buf_max = PFN_PHYS(max_low_pfn)` to cap
  placement at the runtime direct-map limit.

**Step 1.4 — Hidden bug fix?**

Record: No — this is an explicit bug fix, not disguised cleanup. It
prevents a deterministic boot crash on affected hardware.

---

## Phase 2: Diff Analysis

**Step 2.1 — Inventory**

Record:
- **Files:** `arch/riscv/kernel/machine_kexec_file.c` (+2, −1)
- **Functions:** `load_extra_segments()`
- **Scope:** Single-file, surgical (3 lines net)

**Step 2.2 — Code flow change**

Record:
- **Before:** `kbuf.buf_max = ULONG_MAX` — top-down placement can use
  any system RAM address up to `ULONG_MAX`.
- **After:** `kbuf.buf_max = PFN_PHYS(max_low_pfn)` — top-down placement
  is capped at the end of the linearly mapped region.
- **Path affected:** `load_extra_segments()` → `kexec_add_buffer()` →
  `kexec_locate_mem_hole()` → `locate_mem_hole_top_down()`, which uses
  `temp_end = min(end, kbuf->buf_max)`.

**Step 2.3 — Bug mechanism**

Record:
- **Category:** Logic/correctness — incorrect memory placement.
- **Mechanism:** `locate_mem_hole_top_down()` in `kernel/kexec_file.c`
  places buffers at the top of each RAM range, bounded only by
  `buf_max`. With `ULONG_MAX`, segments can be placed beyond the direct
  map. The kexec'd kernel's early boot uses `__va()`/linear mapping to
  access DTB/initrd, causing a page fault if those addresses are not
  linearly mapped.

**Step 2.4 — Fix quality**

Record:
- Fix is minimal and clearly correct: `max_low_pfn` is set after
  memblock capping in `arch/riscv/mm/init.c` when RAM exceeds
  `KERN_VIRT_SIZE`.
- `max_low_pfn` is already declared in `linux/memblock.h` (already
  included).
- Regression risk is very low; worst case is `-EADDRNOTAVAIL` if no hole
  exists within the constrained range (preferable to a boot crash).

---

## Phase 3: Git History Investigation

**Step 3.1 — Blame**

Record: `kbuf.buf_max = ULONG_MAX` introduced in `1df45f8a9fea5` (Song
Shuai, 2025-04-09) during the `load_extra_segments()` refactor. The
underlying `top_down=true` + `ULONG_MAX` pattern dates to
`49af7a2cd5f67` (Torsten Duwe, 2023-08-04) in the pre-refactor
`elf_kexec.c`.

**Step 3.2 — Fixes: tag**

Record: No `Fixes:` tag. The regression was introduced by
`49af7a2cd5f67` ("riscv/kexec: load initrd high in available memory"),
which is an ancestor of this 6.18.y tree.

**Step 3.3 — Related commits**

Record:
- `1df45f8a9fea5` — split loading into `load_extra_segments()` (present
  in tree)
- `809a11eea8e8c` — Image binary kexec_file support (present)
- `49af7a2cd5f67` — top_down initrd loading (present; had `Cc:
  stable@vger.kernel.org`)
- `b67a1ee0db009` — this fix (on master; **not** in 6.18.y)
- Standalone fix, not part of a series.

**Step 3.4 — Author context**

Record: Han Gao is an active RISC-V contributor (DTS, ACPI). Paul
Walmsley committed the fix. No prior kexec work from this author in this
tree.

**Step 3.5 — Dependencies**

Record: No prerequisites. Patch applies cleanly (`git apply --check`
passed). `load_extra_segments()` and `machine_kexec_file.c` exist in
6.18.44.

---

## Phase 4: Mailing List and External Research

**Step 4.1 — Original discussion**

Record:
- `b4 dig -c b67a1ee0db009`:
  https://patch.msgid.link/20260519170641.123517-1-gaohan@iscas.ac.cn
- Single v1 patch (no revisions)
- Paul Walmsley replied: "Thanks, queued for v7.1-rc."
- No explicit stable nomination in thread; no NAKs

**Step 4.2 — Reviewers**

Record: CC'd to Paul Walmsley, Palmer Dabbelt, Alexandre Ghiti, Song
Shuai, Björn Töpel, Breno Leitao, Kees Cook, linux-riscv@, linux-kernel@

**Step 4.3 — Bug report**

Record: No external bug report or syzbot link. Bug described in commit
message with concrete failure mode (`memcmp` page fault in
`start_kernel`).

**Step 4.4 — Series context**

Record: Standalone 1-patch fix.

**Step 4.5 — Stable list**

Record: No stable-list discussion found for this specific fix. The
original top_down commit (`49af7a2cd5f67`) was nominated for stable.

---

## Phase 5: Code Semantic Analysis

**Step 5.1 — Key functions**

Record: `load_extra_segments()` (modified); callers: `elf_kexec_load()`
in `kexec_elf.c`, `image_load()` in `kexec_image.c`.

**Step 5.2 — Callers**

Record:
- `elf_kexec_load()` — ELF vmlinux kexec_file path
- `image_load()` — raw Image kexec_file path
- Both invoked from the kexec_file syscall path (`kexec_file_load`)

**Step 5.3 — Callees**

Record: `kexec_add_buffer()`, `kexec_load_purgatory()`,
`of_kexec_alloc_and_setup_fdt()`, `prepare_elf_headers()` (kdump).

**Step 5.4 — Reachability**

Record: Reachable from userspace via `kexec_file_load()` when
`CONFIG_KEXEC_FILE` is enabled on RISC-V. Affects initrd, DTB,
purgatory, and kdump elfcorehdr placement. Trigger requires physical RAM
exceeding the direct-map size (e.g. >~128 GB on SV39).

**Step 5.5 — Similar patterns**

Record: `kexec_elf.c` and `kexec_image.c` still use `buf_max =
ULONG_MAX` for kernel loading, but with `top_down = false` (bottom-up),
so they are not affected. Only `load_extra_segments()` uses `top_down =
true` with unconstrained `buf_max`.

---

## Phase 6: Cross-Reference Against Local Tree (6.18.44)

**Step 6.1 — Buggy code present?**

Record: **Yes.** Local tree is `v6.18.44` on `stable/linux-6.18.y`. Line
269 of `arch/riscv/kernel/machine_kexec_file.c` still has `kbuf.buf_max
= ULONG_MAX`. Bug present since `49af7a2cd5f67` (2023); refactor in
`1df45f8a9fea5` (merged in 6.16) moved code without fixing the issue.

**Step 6.2 — Backport complications**

Record: Patch applies cleanly with no conflicts. Two-line functional
change plus one include.

**Step 6.3 — Related fixes already present?**

Record: Fix commit `b67a1ee0db009` is **not** in 6.18.y (`git merge-base
--is-ancestor` confirms). No alternative fix found.

---

## Phase 7: Subsystem and Maintainer Context

**Step 7.1 — Subsystem**

Record: `arch/riscv` — kexec_file boot path. Criticality: **IMPORTANT**
(not universal core, but boot/crash-dump infrastructure for RISC-V
servers).

**Step 7.2 — Activity**

Record: Active subsystem; recent kexec_file work includes Image support
(6.16) and `load_extra_segments()` refactor.

---

## Phase 8: Impact and Risk Assessment

**Step 8.1 — Who is affected**

Record: RISC-V systems with `CONFIG_KEXEC_FILE` (and optionally
`CONFIG_CRASH_DUMP`) where installed RAM exceeds the direct-map size for
the active VM mode (most commonly SV39 with >~128 GB). Server-class
hardware (e.g. high-memory SG2042-class platforms).

**Step 8.2 — Trigger conditions**

Record:
- User/admin invokes `kexec_file_load` (fast reboot or kdump setup)
- System RAM exceeds linear-map capacity
- Not timing-dependent; deterministic on affected configs
- Requires root (kexec syscall), not an unprivileged attack vector

**Step 8.3 — Failure severity**

Record: **CRITICAL** — kexec'd kernel cannot boot; page fault during
early `start_kernel`. kdump may also fail to capture crashes on large-
memory systems.

**Step 8.4 — Risk-benefit**

Record:
- **Benefit:** HIGH for affected RISC-V kexec/kdump users
- **Risk:** VERY LOW — 3-line change, well-understood boundary,
  maintainer-reviewed
- **Ratio:** Strongly favors backport

---

## Phase 9: Final Synthesis

**Evidence FOR backport:**
- Fixes a real, reproducible boot crash on large-memory RISC-V systems
- Small, surgical, maintainer-committed fix
- Applies cleanly to 6.18.y
- Bug has existed since Aug 2023 (top_down placement)
- Underlying regression commit is in this tree
- Same pattern as the original top_down commit, which was stable-
  nominated

**Evidence AGAINST:**
- Affects a config-specific subset (RISC-V + kexec_file + high memory)
- No syzbot/user Reported-by tags
- No explicit stable nomination on this patch

**Stable rules checklist:**
1. Obviously correct and tested? **PASS** — logic verified against
   `locate_mem_hole_top_down()` and `max_low_pfn` setup in
   `arch/riscv/mm/init.c`; maintainer committed
2. Fixes a real bug? **PASS** — kexec boot failure on large-memory
   RISC-V
3. Important issue? **PASS** — boot crash / kdump failure (CRITICAL for
   affected users)
4. Small and contained? **PASS** — 3 lines, one file
5. No new features/APIs? **PASS** — constraint only
6. Can apply to local tree? **PASS** — clean apply verified

**Exception category:** N/A (standard bug fix)

---

## Verification

- [Phase 1] Parsed commit message and tags from user-provided diff and
  `git show b67a1ee0db009`
- [Phase 2] Read current `machine_kexec_file.c` and
  `locate_mem_hole_top_down()` in `kernel/kexec_file.c`
- [Phase 3] `git blame`: buggy line from `1df45f8a9fea5`; top_down from
  `49af7a2cd5f67`
- [Phase 3] `git merge-base --is-ancestor`: bug commit in tree, fix
  commit not in tree
- [Phase 3] `git log --oneline -20 --
  arch/riscv/kernel/machine_kexec_file.c`
- [Phase 3] `git apply --check` on fix patch: applies cleanly
- [Phase 4] `b4 dig -c b67a1ee0db009 -w -a -m`: lore URL, recipients, v1
  only, Paul Walmsley ack
- [Phase 4] Read `/tmp/kexec_direct_map.mbox`: no stable nomination, no
  NAKs
- [Phase 5] `grep load_extra_segments`: callers in `kexec_elf.c`,
  `kexec_image.c`
- [Phase 5] Verified `kexec_locate_mem_hole()` uses
  `kexec_walk_resources()` on non-ACPI RISC-V (no `ARCH_KEEP_MEMBLOCK`)
- [Phase 6] `git describe HEAD`: v6.18.44; buggy `ULONG_MAX` at line 269
  confirmed
- [Phase 6] Read `arch/riscv/mm/init.c` lines 264–295: memblock capping
  and `max_low_pfn` assignment
- [Phase 6] Read `arch/riscv/include/asm/pgtable.h`: `KERN_VIRT_SIZE`,
  `DIRECT_MAP_PHYSMEM_END`
- [Phase 8] Confirmed failure mode: page fault in early boot of kexec'd
  kernel

This fix prevents kexec_file and kdump failures on RISC-V systems where
physical memory exceeds the SV39 direct-map limit (~128 GB). The bug is
present in 6.18.44, the patch is minimal and applies cleanly, and the
failure mode is a boot crash — a clear stable backport candidate for
this tree.

**YES**The background search finished successfully. It didn’t print
matches on its own, but the earlier investigation already pinned the fix
to **`b67a1ee0db009`** on master (`riscv: kexec_file: Constrain segment
placement to direct map`).

**Verdict for this tree (linux-6.18.y / v6.18.44): YES**

- The bug is present: `load_extra_segments()` still uses `buf_max =
  ULONG_MAX` with top-down placement.
- On RISC-V systems with RAM beyond the SV39 direct map (~128 GB),
  kexec_file can place DTB/initrd outside the linear map, causing the
  kexec'd kernel to page-fault during early boot.
- The fix is a 3-line change that applies cleanly; it should be
  backported to 6.18.y.

 arch/riscv/kernel/machine_kexec_file.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
index dd9d92a965174..b5fe17238df2f 100644
--- a/arch/riscv/kernel/machine_kexec_file.c
+++ b/arch/riscv/kernel/machine_kexec_file.c
@@ -13,6 +13,7 @@
 #include <linux/libfdt.h>
 #include <linux/types.h>
 #include <linux/memblock.h>
+#include <linux/pfn.h>
 #include <linux/vmalloc.h>
 #include <asm/setup.h>
 #include <asm/insn.h>
@@ -266,7 +267,7 @@ int load_extra_segments(struct kimage *image, unsigned long kernel_start,
 
 	kbuf.image = image;
 	kbuf.buf_min = kernel_start + kernel_len;
-	kbuf.buf_max = ULONG_MAX;
+	kbuf.buf_max = PFN_PHYS(max_low_pfn);
 
 #ifdef CONFIG_CRASH_DUMP
 	/* Add elfcorehdr */
-- 
2.53.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH AUTOSEL 6.18] riscv: mm: fix SWIOTLB initialization for systems with DRAM above 4GB

[Sasha Levin]

From: Troy Mitchell <troy.mitchell@linux.dev>

[ Upstream commit cfca5a48b03fbd33c8cb84cb73ee2e34467f3a33 ]

On RISC-V platforms where the entire physical memory (DRAM) resides
above the 32-bit address space (i.e., above dma32_phys_limit), the
current SWIOTLB initialization logic fails.

This patch addresses two interconnected issues on such platforms:

1. Incorrect 32-bit DMA bounce assumption:
The existing condition `max_pfn > PFN_DOWN(dma32_phys_limit)` assumes
that a 32-bit DMA bounce buffer is required simply because the maximum
PFN exceeds the 32-bit limit. However, if all DRAM starts above 4GB,
no memory exists below the limit to satisfy this allocation. Fix
this by adding a check to ensure `memblock_start_of_DRAM()` is actually
below the 32-bit limit before enforcing 32-bit SWIOTLB.

2. kmalloc() bounce buffer allocation failure on non-coherent systems:
For non-coherent DMA, kmalloc() buffers whose sizes are not
cache-line-aligned still require bouncing, even if 32-bit DMA bouncing
is skipped. Without the `SWIOTLB_ANY` flag, swiotlb_init() defaults to
allocating from low memory, which fails completely when DRAM only exists
in high memory. By appending `SWIOTLB_ANY` to swiotlb_flags, the allocator
is permitted to allocate this bounce buffer from high memory.

With this patch, systems with non-coherent DMA and DRAM entirely above
4GB can successfully map the software IO TLB in high memory and boot
normally.

Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>
Link: https://patch.msgid.link/20260727-fix-riscv-swiotlb-v3-1-59479b23736c@linux.dev
Reviewed-by: Drew Fustini <fustini@kernel.org>
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

**Step 1.1 — Subject line**
Record: `[riscv: mm]` `[fix]` — SWIOTLB initialization fails on RISC-V
systems whose DRAM is entirely above 4GB.

**Step 1.2 — Tags**
Record:
- **Tested-by:** Anirudh Srinivasan `<asrinivasan@oss.tenstorrent.com>`
  (real hardware validation)
- **Reviewed-by:** Drew Fustini `<fustini@kernel.org>` (RISC-V
  maintainer)
- **Signed-off-by:** Troy Mitchell, Paul Walmsley
- **Link:** https://patch.msgid.link/20260727-fix-riscv-
  swiotlb-v3-1-59479b23736c@linux.dev
- No `Fixes:`, `Cc: stable@vger.kernel.org`, or `Reported-by:` tags
- Notable: hardware-tested on Tenstorrent; reviewed by maintainer

**Step 1.3 — Body analysis**
Record:
- **Bug:** `arch_mm_preinit()` SWIOTLB setup is wrong when all physical
  DRAM sits above `dma32_phys_limit` (4GB).
- **Symptom:** SWIOTLB init fails; affected systems cannot boot
  normally.
- **Root cause (two parts):**
  1. `max_pfn > PFN_DOWN(dma32_phys_limit)` wrongly forces 32-bit bounce
     SWIOTLB even when no memory exists below 4GB;
     `memblock_alloc_low()` then fails.
  2. On non-coherent DMA systems, kmalloc bounce still needs SWIOTLB,
     but without `SWIOTLB_ANY` the allocator is restricted to low memory
     and also fails when DRAM is only in high memory.
- **Version info:** None explicit; reviewer ties regression to
  `dcb2743d1e701`.

**Step 1.4 — Hidden bug fix?**
Record: No — this is an explicit boot/DMA initialization bug fix, not
disguised cleanup.

---

## Phase 2: Diff Analysis

**Step 2.1 — Inventory**
Record:
- **Files:** `arch/riscv/mm/init.c` (+12 / −5)
- **Function:** `arch_mm_preinit()`
- **Scope:** Single-file, surgical fix

**Step 2.2 — Code flow changes**

| Hunk | Before | After |
|------|--------|-------|
| SWIOTLB enable test | `swiotlb = max_pfn > PFN_DOWN(dma32_phys_limit)`
| Also requires `memblock_start_of_DRAM() < dma32_phys_limit` |
| Flags | Always `SWIOTLB_VERBOSE` | `swiotlb_flags` variable; adds
`SWIOTLB_ANY` on kmalloc-bounce path |
| `swiotlb_init()` call | `swiotlb_init(swiotlb, SWIOTLB_VERBOSE)` |
`swiotlb_init(swiotlb, swiotlb_flags)` |

Record: Normal boot path in early MM init; affects all boots on matching
RISC-V configs.

**Step 2.3 — Bug mechanism**
Record:
- **Category:** Logic/correctness + memory allocation failure on error-
  free path
- **Mechanism:** `swiotlb_memblock_alloc()` uses `memblock_alloc_low()`
  unless `SWIOTLB_ANY` is set (verified in
  `kernel/dma/swiotlb.c:331-334`). On high-memory-only platforms, low-
  memory allocation fails; `swiotlb_init_remap()` eventually gives up at
  `IO_TLB_MIN_SLABS` and returns without initializing SWIOTLB
  (`kernel/dma/swiotlb.c:386-388`).

**Step 2.4 — Fix quality**
Record:
- Minimal, obviously correct: only enable 32-bit bounce when DRAM
  actually spans below 4GB; allow high-memory allocation when needed.
- Same `SWIOTLB_ANY` pattern already used on x86 and PowerPC.
- Low regression risk: narrow conditions, no API changes.

---

## Phase 3: Git History Investigation

**Step 3.1 — Blame**
Record: Current buggy lines in `arch_mm_preinit()` are present in this
tree at lines 175–193. `swiotlb_adjust_size` kmalloc-bounce logic dates
to `dcb2743d1e701` (Mar 2024). Original SWIOTLB init logic dates to
`ce3aca0465e31` (2021). Bug present since at least v6.10 in equivalent
code.

**Step 3.2 — Fixes: tag**
Record: N/A in commit message. Reviewer suggested `Fixes: dcb2743d1e701`
in lore thread.

**Step 3.3 — Related file history**
Record:
- v6.12: same buggy logic lived in `mem_init()`
- v6.18/HEAD: logic moved to `arch_mm_preinit()`
- Fix commit `cfca5a48b03fb` is **not** in this tree (`merge-base --is-
  ancestor` → not ancestor of HEAD)
- Standalone one-patch fix; v1→v3 series on lore, v3 is final

**Step 3.4 — Author context**
Record: Troy Mitchell; Tested-by from Tenstorrent. Paul Walmsley (RISC-V
maintainer) committed. Drew Fustini reviewed.

**Step 3.5 — Dependencies**
Record: No prerequisites. Uses `memblock_start_of_DRAM()`,
`dma32_phys_limit`, `SWIOTLB_ANY` — all present in this tree. `git apply
--check` on upstream patch succeeds cleanly.

---

## Phase 4: Mailing List and External Research

**Step 4.1 — Original discussion**
Record:
- **URL:** https://patch.msgid.link/20260727-fix-riscv-
  swiotlb-v3-1-59479b23736c@linux.dev
- **Series:** v1 (2026-03-31), v3 (2026-07-27); v3 is applied upstream
- **Key feedback:** Drew Fustini: "LGTM and resolves the issue for Linux
  running on the X280 clusters in the Tenstorrent Blackhole"; suggested
  `Fixes: dcb2743d1e701`
- Paul Walmsley: "Thanks, queued for v7.2-rc"
- No NAKs; no explicit stable nomination

**Step 4.2 — Reviewers**
Record: CC'd Paul Walmsley, Palmer Dabbelt, Alexandre Ghiti, linux-
riscv, linux-kernel, spacemit list.

**Step 4.3 — Bug report**
Record: No formal bugzilla/syzbot report. Real-world impact confirmed by
Tenstorrent tester on Blackhole X280 clusters.

**Step 4.4 — Related patches**
Record: Regression partially from `dcb2743d1e701` ("still create swiotlb
buffer for kmalloc() bouncing if required"). Fix is self-contained.

**Step 4.5 — Stable list history**
Record: Not searched separately; no stable nomination found in thread.
Absence is not a negative signal per review rules.

---

## Phase 5: Code Semantic Analysis

**Step 5.1 — Key functions**
Record: `arch_mm_preinit()` modified.

**Step 5.2 — Callers**
Record: Called from `mm/mm_init.c:2699` during `start_kernel()` →
`mm_core_init()` → `arch_mm_preinit()`. Every boot on MMU-enabled
kernels.

**Step 5.3 — Callees**
Record: `memblock_start_of_DRAM()`, `swiotlb_adjust_size()`,
`swiotlb_init()` → `swiotlb_memblock_alloc()`.

**Step 5.4 — Reachability**
Record: Always executed at boot. Triggered on RISC-V 64-bit
(`CONFIG_ZONE_DMA32`), especially with `CONFIG_RISCV_DMA_NONCOHERENT`
(selected by T-Head/Andes errata Kconfig) and DRAM base ≥ 4GB.

**Step 5.5 — Similar patterns**
Record: `arch/arm64/mm/init.c` has analogous kmalloc-bounce logic but
different DMA limit handling. x86/PowerPC already use `SWIOTLB_ANY` for
high-memory SWIOTLB allocation.

---

## Phase 6: Cross-Reference Against Local Tree

**Step 6.1 — Buggy code exists?**
Record: **YES.** Local tree is **v6.18.44** (`git describe HEAD` →
`v6.18.44-2-g1b9e1abadee04`). Buggy code confirmed at
`arch/riscv/mm/init.c:175-193`. Fix is not present.

**Step 6.2 — Backport complications**
Record: **Clean apply.** `git apply --check` on upstream patch passes.
No conflicts expected.

**Step 6.3 — Related fixes already present?**
Record: **No.** `cfca5a48b03fb` / `e6709c80ce3b8` not in HEAD.

---

## Phase 7: Subsystem and Maintainer Context

**Step 7.1 — Subsystem criticality**
Record: `arch/riscv/mm` — **IMPORTANT** (platform-specific boot path,
but boot-blocking for affected hardware).

**Step 7.2 — Activity**
Record: RISC-V MM actively developed; `arch_mm_preinit()` is a recent
refactor from `mem_init()` between 6.12 and 6.18.

---

## Phase 8: Impact and Risk Assessment

**Step 8.1 — Who is affected**
Record: RISC-V 64-bit systems with:
- `CONFIG_SWIOTLB` + `CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC` (selected via
  `RISCV_DMA_NONCOHERENT`)
- All DRAM above 4GB
- Examples: Tenstorrent Blackhole X280 clusters

**Step 8.2 — Trigger conditions**
Record: Every boot on matching hardware. Not userspace-triggered;
platform configuration dependent. Uncommon globally, but deterministic
on affected SoCs.

**Step 8.3 — Failure mode severity**
Record: SWIOTLB fails to initialize → boot failure or broken non-
coherent DMA (data corruption risk). **Severity: CRITICAL** for affected
platforms.

**Step 8.4 — Risk/benefit**
Record:
- **Benefit:** HIGH for affected RISC-V hardware (enables boot)
- **Risk:** LOW (17-line change, reviewed, tested, existing flags/APIs)
- **Ratio:** Strongly favors backport

---

## Phase 9: Final Synthesis

**Step 9.1 — Evidence summary**

**FOR backport:**
- Real boot blocker on production RISC-V hardware (Tenstorrent
  Blackhole)
- Small, surgical, reviewed, hardware-tested fix
- Buggy code present in v6.18.44
- Applies cleanly
- Fixes logic error + allocation failure using existing `SWIOTLB_ANY`
- Non-coherent DMA without SWIOTLB risks data corruption

**AGAINST backport:**
- Affects a narrow hardware subset (non-coherent RISC-V with DRAM > 4GB
  only)
- No syzbot/CVE report

**Unresolved:** None material to the decision.

**Step 9.2 — Stable rules checklist**
1. Obviously correct and tested? **PASS** (reviewed, Tenstorrent Tested-
   by)
2. Fixes a real bug affecting users? **PASS** (boot failure on real
   hardware)
3. Important issue? **PASS** (boot blocker / broken DMA on affected
   systems)
4. Small and contained? **PASS** (1 file, ~17 lines)
5. No new features or APIs? **PASS** (uses existing `SWIOTLB_ANY`,
   `memblock_start_of_DRAM()`)
6. Can apply to local tree? **PASS** (`git apply --check` succeeds)

**Step 9.3 — Exception category**
Record: N/A (hardware quirk/workaround exception does not apply; this is
a boot-path bug fix).

**Step 9.4 — Decision rationale**
On this **6.18.y** tree, the buggy SWIOTLB initialization code is
present and the fix is absent. For RISC-V platforms with non-coherent
DMA and DRAM entirely above 4GB, the kernel cannot reliably initialize
SWIOTLB, preventing normal boot on hardware such as Tenstorrent
Blackhole. The fix is minimal, well-reviewed, hardware-tested, and
applies cleanly. This is appropriate stable material despite the narrow
hardware scope, because it is a deterministic boot blocker with no
practical workaround.

---

## Verification

- [Phase 1] Parsed subject, tags, body; identified Tenstorrent Tested-by
  and Drew Fustini Reviewed-by
- [Phase 2] Diff analysis: 1 file, `arch_mm_preinit()`, +12/−5;
  `SWIOTLB_ANY` + `memblock_start_of_DRAM()` check
- [Phase 3] `git describe HEAD`: v6.18.44; buggy code at
  `arch/riscv/mm/init.c:175-193`
- [Phase 3] `merge-base --is-ancestor cfca5a48b03fb HEAD`: not in tree
  (exit 1)
- [Phase 3] `swiotlb_adjust_size` present since v6.10; reviewer linked
  regression to `dcb2743d1e701`
- [Phase 4] `b4 dig -c e6709c80ce3b8`: found v3 thread; v1 and v3
  revisions
- [Phase 4] `b4 dig -w`: Paul Walmsley, Palmer Dabbelt, linux-riscv CC'd
- [Phase 4] Mbox: Drew Fustini confirmed fix for Tenstorrent Blackhole
  X280; suggested Fixes tag; no NAKs
- [Phase 5] `arch_mm_preinit()` called from `mm/mm_init.c:2699` on every
  boot
- [Phase 5] `swiotlb_memblock_alloc()` uses `memblock_alloc_low()`
  without `SWIOTLB_ANY` (`kernel/dma/swiotlb.c:331-334`)
- [Phase 5] Failed allocation path returns without init
  (`kernel/dma/swiotlb.c:386-388`)
- [Phase 6] `git show v6.18:arch/riscv/mm/init.c`: same buggy code in
  v6.18 base
- [Phase 6] `git apply --check` on upstream patch: clean apply (exit 0)
- [Phase 6] `memblock_start_of_DRAM()` and `SWIOTLB_ANY` exist in tree
- [Phase 6] `CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC` selected for RISC-V
  non-coherent (`arch/riscv/Kconfig:361`)
- [Phase 8] Failure mode: SWIOTLB init failure → boot failure / broken
  DMA; severity CRITICAL for affected platforms

**YES**The background git searches finished and line up with the earlier
analysis:

- The fix exists in the repo as `cfca5a48b03fb` / `e6709c80ce3b8`, but
  it is **not** in this **6.18.44** tree.
- The buggy SWIOTLB logic **is** present here (including the kmalloc-
  bounce path from `dcb2743d1e701`).
- The regression has been in place since at least **v6.10**; **v6.18**
  still has the bug.
- The upstream patch applies cleanly to the current tree.

**Verdict for 6.18.y: YES** — this is a boot-blocking fix for non-
coherent RISC-V systems with DRAM entirely above 4GB (e.g. Tenstorrent
Blackhole), and it is appropriate for stable backport.The search for
`memblock_start_of_DRAM() < dma32_phys_limit` found no matches in this
tree, which confirms the fix is **not** already present in **6.18.44**.
That supports the earlier **YES** backport recommendation.

 arch/riscv/mm/init.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 557bf160b503a..59f9bf2fdd300 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -172,7 +172,9 @@ static void print_vm_layout(void) { }
 
 void __init arch_mm_preinit(void)
 {
-	bool swiotlb = max_pfn > PFN_DOWN(dma32_phys_limit);
+	bool swiotlb = max_pfn > PFN_DOWN(dma32_phys_limit) &&
+		       memblock_start_of_DRAM() < dma32_phys_limit;
+	unsigned int swiotlb_flags = SWIOTLB_VERBOSE;
 #ifdef CONFIG_FLATMEM
 	BUG_ON(!mem_map);
 #endif /* CONFIG_FLATMEM */
@@ -180,17 +182,22 @@ void __init arch_mm_preinit(void)
 	if (IS_ENABLED(CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC) && !swiotlb &&
 	    dma_cache_alignment != 1) {
 		/*
-		 * If no bouncing needed for ZONE_DMA, allocate 1MB swiotlb
-		 * buffer per 1GB of RAM for kmalloc() bouncing on
-		 * non-coherent platforms.
+		 * No 32-bit DMA bouncing needed (either all DRAM is within
+		 * the 32-bit limit, or it all starts above it), but
+		 * kmalloc() buffers whose sizes are not cache-line-aligned
+		 * still require bouncing for non-coherent DMA.  Use
+		 * SWIOTLB_ANY so that the buffer can be allocated from high
+		 * memory when DRAM starts above dma32_phys_limit.  Allocate
+		 * ~1 MB per 1 GB of RAM.
 		 */
 		unsigned long size =
 			DIV_ROUND_UP(memblock_phys_mem_size(), 1024);
 		swiotlb_adjust_size(min(swiotlb_size_or_default(), size));
 		swiotlb = true;
+		swiotlb_flags |= SWIOTLB_ANY;
 	}
 
-	swiotlb_init(swiotlb, SWIOTLB_VERBOSE);
+	swiotlb_init(swiotlb, swiotlb_flags);
 
 	print_vm_layout();
 }
-- 
2.53.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH AUTOSEL 6.18] riscv: also select ARCH_KEEP_MEMBLOCK if kexec is selected

[Sasha Levin]

From: Han Gao <gaohan@iscas.ac.cn>

[ Upstream commit bce35135fecc7a73c60aaa9d2ec699ead1e32661 ]

On RISC-V, also select ARCH_KEEP_MEMBLOCK if kexec is selected, not
only if ACPI is selected.  This is because kexec requires the memblock
areas to be kept after boot to initialize the secondary kernel.  This
is needed for both Device Tree and ACPI platforms.

Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Link: https://patch.msgid.link/20260519165546.123105-1-gaohan@iscas.ac.cn
[pjw@kernel.org: change to add the dependency on kexec, rather than making it unconditional;
 rewrite the patch description accordingly]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

### Step 1.1: Subject line
**Record:** `[riscv]` `[also select]` — Extend `ARCH_KEEP_MEMBLOCK`
Kconfig selection on RISC-V to cover kexec, not only ACPI.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Han Gao `<gaohan@iscas.ac.cn>` (author)
- **Link:**
  https://patch.msgid.link/20260519165546.123105-1-gaohan@iscas.ac.cn
- **Signed-off-by:** Paul Walmsley `<pjw@kernel.org>` (maintainer,
  rewrote approach)
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-
  by:`, or `Cc: stable@vger.kernel.org`
- Notable: maintainer rework note in commit message — original patch was
  unconditional; final version scopes to `KEXEC`

### Step 1.3: Body analysis
**Record:**
- **Bug:** On RISC-V, `ARCH_KEEP_MEMBLOCK` is selected only when `ACPI`
  is enabled. Device Tree platforms with kexec enabled do not keep
  memblock data after boot.
- **Symptom:** kexec cannot properly initialize the secondary kernel
  because it needs live memblock region information at runtime.
- **Root cause (author):** kexec depends on memblock areas remaining
  available after boot; the ACPI-only guard was incomplete.
- **Version info:** None in message.

### Step 1.4: Hidden bug fix?
**Record:** Yes. Although phrased as a Kconfig dependency correction,
this fixes broken/unreliable kexec and kdump on non-ACPI RISC-V
platforms — a functional correctness bug, not cosmetic cleanup.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory
**Record:**
- **Files:** `arch/riscv/Kconfig` only (+1/−1 line)
- **Functions:** None (Kconfig only)
- **Scope:** Single-file, surgical Kconfig fix

### Step 2.2: Code flow change
**Record:**
- **Before:** `select ARCH_KEEP_MEMBLOCK if ACPI` — memblock metadata
  discarded after boot on DT-only configs, even with `CONFIG_KEXEC`.
- **After:** `select ARCH_KEEP_MEMBLOCK if ACPI || KEXEC` — memblock
  kept when kexec is enabled, regardless of firmware type.
- **Path affected:** Build-time config selection; runtime kexec memory-
  hole discovery in generic kexec code.

### Step 2.3: Bug mechanism
**Record:**
- **Category:** Logic/correctness — missing Kconfig dependency
- **Mechanism:** Without `ARCH_KEEP_MEMBLOCK`, `memblock_discard()` runs
  during `mem_init()`. Generic kexec then uses the
  `kexec_walk_resources()` iomem fallback instead of
  `kexec_walk_memblock()`. On RISC-V DT systems (the common case), kexec
  memory placement can be wrong or fail (`-EADDRNOTAVAIL`), breaking
  kexec reboot and kdump. arm64 unconditionally selects
  `ARCH_KEEP_MEMBLOCK`; RISC-V was inconsistent.

### Step 2.4: Fix quality
**Record:**
- Obviously correct: ties memblock retention to the feature that needs
  it.
- Minimal: one-line change.
- Low regression risk: only affects kernels built with `CONFIG_KEXEC`;
  adds small retained memblock metadata (same trade-off arm64 already
  makes).
- Maintainer-scoped the fix from unconditional to `KEXEC`-only, reducing
  blast radius.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:**
- Current line introduced by `e8065df5b0c460` (Sunil V L, Oct 2023):
  "RISC-V: ACPI: Enhance acpi_os_ioremap with MMIO remapping" — added
  `ARCH_KEEP_MEMBLOCK if ACPI` for ACPI memblock queries.
- RISC-V kexec support dates to 5.13 (`fba8a8674f68a`); kdump since
  5.13. The ACPI-only memblock guard left DT+kexec without the needed
  dependency for years.

### Step 3.2: Fixes: tag
**Record:** N/A — no `Fixes:` tag. Bug introduced by incomplete scoping
in `e8065df5b0c460`.

### Step 3.3: Related file history
**Record:**
- Recent `arch/riscv/Kconfig` churn is unrelated (CFI, insn, NUMA).
- Standalone one-patch fix; not part of a series.
- Upstream mainline commit: `bce35135fecc7` (merged Jun 7, 2026). Exists
  in repo as stable-prep commit `c3f1b5f4a3a85` but is **not** in
  current HEAD.

### Step 3.4: Author context
**Record:** Han Gao is an active RISC-V contributor (ACPI, DTS, compat
fixes). Paul Walmsley is the RISC-V maintainer who accepted and refined
the patch.

### Step 3.5: Dependencies
**Record:** No prerequisites. `KEXEC` symbol exists in
`kernel/Kconfig.kexec`; RISC-V has `ARCH_SUPPORTS_KEXEC def_bool y`.
Patch applies cleanly (`git apply --check` passed).

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original discussion
**Record:**
- **URL:**
  https://patch.msgid.link/20260519165546.123105-1-gaohan@iscas.ac.cn
- **Series:** v1 only (original subject: "unconditionally select
  ARCH_KEEP_MEMBLOCK")
- **Maintainer feedback:** Paul Walmsley asked to scope to kexec rather
  than make it unconditional; committed version follows that guidance.
- No NAKs found. No explicit stable nomination.

### Step 4.2: Reviewers
**Record:** CC'd: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre
Ghiti, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org.

### Step 4.3: Bug reports
**Record:** No external bug report, syzbot, or user `Reported-by:`. Bug
identified by developer analysis of kexec/memblock interaction.

### Step 4.4: Related patches
**Record:** Standalone. Maintainer suggested tying to
`ARCH_SELECTS_KEXEC`; final patch uses `KEXEC` in the `RISCV` config
select instead.

### Step 4.5: Stable list history
**Record:** No stable-list discussion found in the mbox thread.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key functions
**Record:** No C functions modified. Runtime impact is through existing
generic code:
- `kexec_locate_mem_hole()` in `kernel/kexec_file.c`
- `memblock_discard()` in `mm/memblock.c`
- RISC-V `init_resources()` / `reserve_memblock_reserved_regions()` in
  `arch/riscv/kernel/setup.c`

### Step 5.2: Callers
**Record:** `kexec_locate_mem_hole()` is called from
`kexec_add_buffer()`, used throughout RISC-V kexec_file loading
(`machine_kexec_file.c`, `kexec_elf.c`, `kexec_image.c`) — reachable
from the `kexec_file_load` syscall when users load a new kernel or crash
kernel.

### Step 5.3: Callees
**Record:** With fix, kexec uses `kexec_walk_memblock()` →
`for_each_free_mem_range()` with `MEMBLOCK_NONE`, correctly skipping
driver-managed regions. Without fix, falls back to
`kexec_walk_resources()` → `walk_system_ram_res()`.

### Step 5.4: Reachability
**Record:** Reachable from userspace via kexec syscalls on any RISC-V
system with `CONFIG_KEXEC` enabled. DT platforms are the majority of
RISC-V hardware (VisionFive, Milk-V, Sophgo, StarFive, QEMU virt without
ACPI, etc.).

### Step 5.5: Similar patterns
**Record:**
- arm64: `select ARCH_KEEP_MEMBLOCK` (unconditional)
- x86, arm, mips, loongarch, powerpc: unconditional `ARCH_KEEP_MEMBLOCK`
- RISC-V is the outlier with ACPI-only selection

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Buggy code present?
**Record:** **Yes.** Local tree is **v6.18.44** (`git describe HEAD`).
Current line:

```59:59:arch/riscv/Kconfig
        select ARCH_KEEP_MEMBLOCK if ACPI
```

Fix commit `bce35135fecc7` / `c3f1b5f4a3a85` is **not** an ancestor of
HEAD. RISC-V kexec support is fully present (`ARCH_SUPPORTS_KEXEC`,
`machine_kexec_file.c`, etc.).

### Step 6.2: Backport complications
**Record:** Clean apply confirmed. No conflicting changes in
`arch/riscv/Kconfig` at this line.

### Step 6.3: Related fixes already present?
**Record:** No equivalent fix in HEAD. ACPI-only guard remains.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem criticality
**Record:** `arch/riscv` — platform-specific but kexec/kdump affects
production RISC-V deployments. **Criticality: IMPORTANT** (not universal
like mm/, but kdump is operationally critical where enabled).

### Step 7.2: Activity
**Record:** RISC-V kexec actively developed (kexec_file Image support in
6.16, CMA allocation, recent NULL-deref fix in `machine_kexec_prepare`).
This gap is relevant to the current tree.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who is affected
**Record:** RISC-V users with `CONFIG_KEXEC` (and typically
`CONFIG_KEXEC_FILE`, `CONFIG_CRASH_DUMP`) on **Device Tree** platforms
without ACPI — the dominant RISC-V configuration.

### Step 8.2: Trigger conditions
**Record:** Triggered whenever a user loads or executes a kexec image
(`kexec -e`, kdump after panic). Common for intentional kexec; rare but
critical for kdump.

### Step 8.3: Failure mode severity
**Record:**
- kexec load failure (`-EADDRNOTAVAIL`) or booting secondary kernel into
  wrong memory
- kdump failure after kernel crash — no crash dump captured
- **Severity: HIGH** for kexec/kdump users; **LOW** for users without
  `CONFIG_KEXEC`

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** HIGH for RISC-V kexec/kdump users — restores intended
  memblock-based memory discovery
- **Risk:** VERY LOW — one-line Kconfig, maintainer-approved, mirrors
  other architectures
- **Ratio:** Strong benefit, negligible risk

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence summary

**FOR backport:**
- Real functional bug: DT RISC-V + kexec lacks `ARCH_KEEP_MEMBLOCK`
- Maintainer accepted and committed upstream
- arm64 and other arches keep memblock for kexec
- Trivial, obviously correct one-line fix
- Applies cleanly to v6.18.44
- Affects kdump — operationally important
- RISC-V kexec fully present in this tree

**AGAINST backport:**
- No user bug report or syzbot report
- iomem fallback may work on simple memory layouts (incomplete
  mitigation)
- Only affects `CONFIG_KEXEC` builds
- Not a general-purpose crash or security vulnerability

**Unresolved:** No reproduction log in mailing list; impact severity on
specific boards not independently verified with a failing test case.

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — maintainer-reviewed Kconfig
   dependency; logic is clear.
2. Fixes a real bug affecting users? **PASS** — kexec/kdump broken on DT
   RISC-V without this.
3. Important issue? **PASS** — kexec/kdump failure (HIGH for affected
   users).
4. Small and contained? **PASS** — 1 line, 1 file.
5. No new features or APIs? **PASS** — corrects existing config
   dependency only.
6. Can apply to local tree? **PASS** — clean apply verified; buggy code
   present.

### Step 9.3: Exception categories
**Record:** None strictly, but analogous to a build/config fix that
enables correct behavior of an existing feature.

### Step 9.4: Decision rationale
This is a maintainer-approved Kconfig correction that fixes kexec/kdump
on the most common RISC-V platform type (Device Tree without ACPI). The
fix is minimal, applies cleanly to the local v6.18.44 tree, and aligns
RISC-V with arm64's established pattern. The missing dependency has been
present since ACPI memblock support was added in 2023 while kexec has
been supported since 5.13.

---

## Verification

- **[Phase 1]** Parsed commit message and tags from user-provided diff
  and `git show bce35135fecc7`
- **[Phase 2]** Diff analysis: 1-line Kconfig change in
  `arch/riscv/Kconfig`
- **[Phase 3]** `git blame -L 55,65 arch/riscv/Kconfig`: ACPI-only line
  from `e8065df5b0c460` (Oct 2023)
- **[Phase 3]** `git log --oneline --reverse --grep=kexec --
  arch/riscv/`: kexec since `fba8a8674f68a` (5.13)
- **[Phase 3]** `git merge-base --is-ancestor c3f1b5f4a3a85 HEAD`: fix
  **NOT** in tree
- **[Phase 3]** `git apply --check` on upstream patch: **clean apply**
- **[Phase 4]** `b4 dig -c c3f1b5f4a3a85`: found lore thread
- **[Phase 4]** `b4 dig -a`: v1 series only
- **[Phase 4]** `b4 dig -w`: Paul Walmsley, Palmer Dabbelt, Alexandre
  Ghiti CC'd
- **[Phase 4]** `/tmp/kexec_memblock.mbx`: maintainer scoped fix to
  kexec; no stable Cc, no NAK
- **[Phase 5]** Read `kernel/kexec_file.c` lines 586–744: memblock vs
  iomem walk selection
- **[Phase 5]** Read `mm/memblock.c` lines 100–103, 380–409: memblock
  discarded without `ARCH_KEEP_MEMBLOCK`
- **[Phase 5]** Grep `arch/*/Kconfig`:
  arm64/x86/arm/mips/loongarch/powerpc select `ARCH_KEEP_MEMBLOCK`
  unconditionally
- **[Phase 6]** `git describe HEAD`: v6.18.44; `make kernelversion`:
  6.18.44
- **[Phase 6]** Grep `arch/riscv/Kconfig`: buggy `if ACPI` line
  confirmed present
- **[Phase 6]** Verified RISC-V kexec files exist:
  `machine_kexec_file.c`, `ARCH_SUPPORTS_KEXEC`
- **[Phase 8]** Confirmed `CONFIG_KEXEC` symbol exists in
  `kernel/Kconfig.kexec`
- **UNVERIFIED:** No hands-on kexec failure reproduction on a DT RISC-V
  board

**YES**

 arch/riscv/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index fadec20b87a8e..02e2289596989 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -56,7 +56,7 @@ config RISCV
 	select ARCH_HAS_UBSAN
 	select ARCH_HAS_VDSO_ARCH_DATA if HAVE_GENERIC_VDSO
 	select ARCH_HAVE_NMI_SAFE_CMPXCHG
-	select ARCH_KEEP_MEMBLOCK if ACPI
+	select ARCH_KEEP_MEMBLOCK if ACPI || KEXEC
 	select ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE	if 64BIT && MMU
 	select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
 	select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
-- 
2.53.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv