[PATCH AUTOSEL 7.0-5.10] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec

[PATCH AUTOSEL 7.0-5.10] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec

[Sasha Levin]

From: Sourabh Jain <sourabhjain@linux.ibm.com>

[ Upstream commit 38e989d504fc52900a3786b7144fb53cd67e0389 ]

The kexec sequence invokes enter_vmx_ops() via copy_page() with the MMU
disabled. In this context, code must not rely on normal virtual address
translations or trigger page faults.

With KASAN enabled, functions get instrumented and may access shadow
memory using regular address translation. When executed with the MMU
off, this can lead to page faults (bad_page_fault) from which the
kernel cannot recover in the kexec path, resulting in a hang.

The kexec path sets preempt_count to HARDIRQ_OFFSET before entering
the MMU-off copy sequence.

current_thread_info()->preempt_count = HARDIRQ_OFFSET
  kexec_sequence(..., copy_with_mmu_off = 1)
    -> kexec_copy_flush(image)
         copy_segments()
           -> copy_page(dest, addr)
	         bl enter_vmx_ops()
                   if (in_interrupt())
                     return 0
	         beq .Lnonvmx_copy

Since kexec sets preempt_count to HARDIRQ_OFFSET, in_interrupt()
evaluates to true and enter_vmx_ops() returns early.

As in_interrupt() (and preempt_count()) are always inlined, mark
enter_vmx_ops() with __no_sanitize_address to avoid KASAN
instrumentation and shadow memory access with MMU disabled, helping
kexec boot fine with KASAN enabled.

Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Reviewed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260407124349.1698552-2-sourabhjain@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record: subsystem `powerpc/vmx`; action verb `avoid`; intent is to
prevent KASAN instrumentation of `enter_vmx_ops()` when it is reached
from the kexec MMU-off copy path.

Record: tags parsed from the candidate message:
- `Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>`
- `Reviewed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>`
- `Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>`
- `Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>`
- `Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>`
- `Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>`
- `Link: https://patch.msgid.link/20260407124349.1698552-2-
  sourabhjain@linux.ibm.com`
- No `Fixes:` tag in this commit. Absence is not a negative signal.

Record: bug description from the message: `kexec_sequence()` may call
`copy_page()` with the MMU disabled; on PowerPC Book3S this can enter
`copypage_power7.S`, which calls `enter_vmx_ops()`. If KASAN instruments
`enter_vmx_ops()`, the instrumentation may access shadow memory using
normal virtual translation, which is invalid with MMU off and can cause
an unrecoverable `bad_page_fault`/hang in kexec.

Record: hidden bug fix: yes. Although phrased as “avoid
instrumentation,” this fixes a real boot/hang failure in the kexec/kdump
path under KASAN.

## Phase 2: Diff Analysis
Record: one file changed: `arch/powerpc/lib/vmx-helper.c`, with 8
insertions and 1 deletion in the fetched v3 patch. The only functional
change is changing `int enter_vmx_ops(void)` to `int
__no_sanitize_address enter_vmx_ops(void)`; the remaining additions are
explanatory comments.

Record: modified function: `enter_vmx_ops()`.

Record: before behavior: `enter_vmx_ops()` could be KASAN-instrumented.
During kexec with MMU off, the function first checks `in_interrupt()`
and should return `0`, but KASAN prologue/body instrumentation can run
before or around normal code and touch shadow memory.

Record: after behavior: `__no_sanitize_address` suppresses KASAN
instrumentation for this function, preserving the intended early return
path when `preempt_count` contains `HARDIRQ_OFFSET`.

Record: bug category: sanitizer/real-mode correctness bug causing kexec
hang. This is a crash/hang class fix, not a cleanup.

Record: fix quality: small, surgical, and low risk. It does not alter
normal logic, public API, data structures, or userspace-visible
behavior. The only behavioral effect is disabling KASAN instrumentation
for one helper that can run in an MMU-off path.

## Phase 3: Git History Investigation
Record: local `HEAD` is a stable release commit, not the candidate. `git
log --grep` on current history, `master`, and `power-next` did not find
the candidate commit locally, so there was no commit hash available for
`b4 dig -c`.

Record: `git blame` on current `arch/powerpc/lib/vmx-helper.c` shows the
unannotated `enter_vmx_ops()` present in the local tree; due this
repository’s history shape, blame attributes the original lines to a
merge/root history point, so the exact original introduction commit was
not verifiable locally.

Record: no candidate `Fixes:` tag to follow. The companion patch in the
same series has `Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address
sanitization in kexec paths")`; `git show` confirms that commit disabled
sanitization for PowerPC kexec real-mode paths in 2022.

Record: related recent local history: `6bc9c0a905228` changed VMX
usercopy flow and added export context around the same file. That
affects hunk context for older stable trees, but not the actual one-line
fix.

Record: author context: `git log --author="Sourabh Jain" --
arch/powerpc/...` shows multiple PowerPC kexec/crash/fadump commits.
`MAINTAINERS` lists Madhavan Srinivasan and Michael Ellerman as PowerPC
maintainers; Madhavan signed off the candidate.

Record: dependencies: no source-level prerequisite for the annotation
itself. Function `enter_vmx_ops()` and `__no_sanitize_address` exist in
checked stable tags. Functional completeness is best with the companion
patch fixing `KASAN_SANITIZE_core_$(BITS).o`, because review/test
discussion says both patches together make KASAN kexec succeed.

## Phase 4: Mailing List And External Research
Record: `b4 am` for message id
`20260407124349.1698552-2-sourabhjain@linux.ibm.com` fetched a v3 two-
patch series. It reported total patches: 2, current tree apply clean,
and DKIM signature valid for patch 2.

Record: `b4 am -c` checked for newer revisions and did not report a
newer v4. v3 appears to be the latest fetched revision.

Record: `b4 mbox` fetched the v3 thread. Patch 2 was addressed to
`linuxppc-dev` and CC’d PowerPC/kexec stakeholders including Michael
Ellerman, Madhavan Srinivasan, Mahesh Salgaonkar, Hari Bathini, Daniel
Axtens, Venkat Rao Bagalkote, Aboorva Devarajan, and Ritesh Harjani.

Record: `WebFetch` of lore URLs was blocked by Anubis, but `b4` and the
`yhbt.net` lore mirror provided the thread content.

Record: v2 review discussion verified:
- Ritesh Harjani reviewed patch 2 and said “LGTM,” granting `Reviewed-
  by`.
- Aboorva Devarajan reported an actual KASAN-enabled kexec hang on
  pseries PowerVM: system reached “kexec: Starting switchover sequence”
  and then hung.
- Aboorva tested that “with both the patches applied, kexec completes
  successfully with KASAN enabled.”
- v1 annotated both `enter_vmx_ops()` and `exit_vmx_ops()`; v2 removed
  `exit_vmx_ops()` annotation and added the explanatory comment. This
  shows review-driven narrowing of the fix.

Record: stable-specific discussion: Ritesh explicitly suggested `Cc:
stable@vger.kernel.org` for patch 1. I did not find a direct stable
nomination for patch 2, but patch 2 was reviewed and tested as part of
the same two-patch functional fix.

## Phase 5: Code Semantic Analysis
Record: modified function: `enter_vmx_ops()`.

Record: callers found by exact search:
- `arch/powerpc/lib/copypage_power7.S`
- `arch/powerpc/lib/memcpy_power7.S`
- `arch/powerpc/lib/memcmp_64.S`

Record: relevant kexec call chain verified in code:
`reboot(LINUX_REBOOT_CMD_KEXEC)` -> `kernel_kexec()` ->
`machine_kexec()` -> `default_machine_kexec()` -> `kexec_sequence()` ->
`kexec_copy_flush()` -> `copy_segments()` -> `copy_page()` ->
`copypage_power7.S` -> `enter_vmx_ops()`.

Record: key callees/logic in `enter_vmx_ops()`: `in_interrupt()`,
`preempt_disable()`, and `enable_kernel_altivec()`. In the kexec MMU-off
path, `default_machine_kexec()` sets
`current_thread_info()->preempt_count = HARDIRQ_OFFSET`, and
`include/linux/preempt.h` defines `in_interrupt()` via `irq_count()`,
which observes the hardirq bits.

Record: reachability: reachable from privileged kexec/kdump paths. It is
not unprivileged-user reachable, but kdump reliability is operationally
important.

Record: similar patterns: PowerPC already disables KASAN for sensitive
real-mode/interrupt code in multiple Makefiles and uses
`__no_sanitize_address` in PowerPC interrupt/stack code, so the
attribute is consistent with local practice.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Record: buggy code exists in stable tags checked: `v5.4`, `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.18`, `v6.19`, and `v7.0` all have
`enter_vmx_ops()` without `__no_sanitize_address`.

Record: the kexec `copy_segments()` -> `copy_page()` path and
`preempt_count = HARDIRQ_OFFSET` were verified in `v5.4`, `v5.10`,
`v5.15`, `v6.1`, and current/v7.0-era code.

Record: `copypage_power7.S` calls `enter_vmx_ops()` in `v5.4`, `v5.10`,
`v5.15`, and current code.

Record: `__no_sanitize_address` exists in compiler headers in checked
stable tags, including `v5.4`, `v5.10`, `v6.1`, `v6.6`, and current.

Record: backport difficulty: clean on current `7.0.y` per `git apply
--check` and `b4`. Older stable trees may need a tiny context adjustment
because `EXPORT_SYMBOL(exit_vmx_usercopy)` is not present in older
versions, but the actual function signature is present and the backport
is straightforward.

Record: related fixes already in stable: not verified as already
present; local stable tags checked do not contain the candidate
annotation.

## Phase 7: Subsystem And Maintainer Context
Record: subsystem is PowerPC architecture library/kexec path:
`arch/powerpc/lib` and `arch/powerpc/kexec`.

Record: criticality: important/platform-specific. It affects PowerPC
systems using kexec/kdump with KASAN enabled, especially pseries/PowerVM
cases verified in review. It is not universal across all architectures.

Record: subsystem activity: local history shows recent PowerPC VMX
usercopy and kexec/crash/fadump activity, and the patch was handled
through the PowerPC maintainer path.

## Phase 8: Impact And Risk Assessment
Record: affected users: PowerPC Book3S/PowerVM-style systems using
kexec/kdump with KASAN-enabled kernels and VMX copy paths.

Record: trigger conditions: kexec/kdump switchover, MMU-off copy path,
KASAN enabled, and `copy_page()` selecting the Power7 VMX copy path. The
triggering operation is privileged, but the failure impacts crash dump
capture and reboot into the new kernel.

Record: failure mode: system hang during kexec/kdump. Review discussion
includes an observed hang after “kexec: Starting switchover sequence,”
and the commit message explains unrecoverable `bad_page_fault` risk with
MMU off. Severity: HIGH to CRITICAL for affected debug/crash-dump
deployments.

Record: benefit: high for affected PowerPC KASAN/kdump users because it
prevents a hard hang and restores kexec completion.

Record: risk: very low. One function annotation plus comment; no logic
change. The main concern is that stable maintainers should also take the
companion Makefile fix for full KASAN/kexec coverage.

## Phase 9: Final Synthesis
Record: evidence for backporting:
- Fixes a real, reviewed, and tested kexec hang with KASAN enabled.
- Aboorva Devarajan reported and tested the failure/fix.
- Ritesh Harjani reviewed the final approach.
- The fix is one function attribute and explanatory comment.
- It affects a serious operational path: kexec/kdump boot into a
  new/capture kernel.
- The buggy code and call path exist across active stable versions
  checked.
- Backport is clean for current `7.0.y` and trivial for older stable
  trees.

Record: evidence against backporting:
- The issue is config/platform specific: PowerPC plus KASAN plus
  kexec/kdump plus VMX copy path.
- Older stable trees may require minor context adjustment.
- The commit is part of a two-patch series; the companion Makefile KASAN
  fix should be included for the tested complete fix.

Record: unresolved questions:
- Exact original introduction commit for `enter_vmx_ops()` could not be
  verified from local history.
- Direct lore `WebFetch` was blocked by Anubis; I used `b4` and a lore
  mirror instead.
- I did not build-test the backport.

Stable rules checklist:
1. Obviously correct and tested: yes. The annotation directly suppresses
   KASAN instrumentation on the one helper that can execute with MMU
   off; tested-by is present.
2. Fixes a real bug: yes. Review discussion reports an actual kexec hang
   with KASAN.
3. Important issue: yes. Failure mode is kexec/kdump hang.
4. Small and contained: yes. One file, one function annotation.
5. No new features/APIs: yes.
6. Can apply to stable: yes for current `7.0.y`; older trees may need
   trivial context adjustment.

Exception category: not a device ID/quirk/build/doc exception. It is a
normal stability fix.

## Verification
- [Phase 1] Parsed the supplied commit message and fetched patch mbox;
  confirmed tags, no `Fixes:` tag in patch 2, and the linked message id.
- [Phase 2] Inspected fetched v3 diff; confirmed `arch/powerpc/lib/vmx-
  helper.c` has 8 insertions and 1 deletion, changing only
  `enter_vmx_ops()`.
- [Phase 3] Ran `git log --grep` on current history, `master`, and
  `power-next`; candidate not present locally.
- [Phase 3] Ran `git blame` around `enter_vmx_ops()`; local history
  could not identify true original introduction beyond repository
  history shape.
- [Phase 3] Ran `git show 2ab2d5794f14`; confirmed related PowerPC kexec
  KASAN sanitization commit from 2022.
- [Phase 4] Ran `b4 am` and `b4 am -c`; fetched v3 two-patch series, no
  newer revision reported, patch 2 DKIM valid.
- [Phase 4] Ran `b4 mbox`; confirmed original recipients and patch
  content.
- [Phase 4] Used lore mirror for v2 thread; confirmed Ritesh review,
  Aboorva tested-by/reported hang, and v1-to-v2 narrowing.
- [Phase 5] Searched call sites; confirmed `copypage_power7.S`,
  `memcpy_power7.S`, and `memcmp_64.S` call `enter_vmx_ops()`.
- [Phase 5] Read kexec and assembly code; confirmed kexec path reaches
  `copy_page()` with MMU-off logic and `preempt_count = HARDIRQ_OFFSET`.
- [Phase 6] Checked stable tags `v5.4` through `v7.0`; confirmed
  `enter_vmx_ops()` exists without the annotation and the relevant
  kexec/copy path exists in checked trees.
- [Phase 6] Ran `git apply --check` on current tree for patch 2 and the
  series; clean on current `7.0.y`.
- [Phase 7] Checked `MAINTAINERS`; confirmed PowerPC maintainers and
  that Madhavan Srinivasan is listed for PowerPC.
- [Phase 8] Verified failure mode from review discussion: KASAN-enabled
  kexec hangs after switchover; with both patches applied, kexec
  completes.

This should be backported, ideally together with the companion
`powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o` patch
for the tested complete KASAN/kexec fix.

**YES**

 arch/powerpc/lib/vmx-helper.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/lib/vmx-helper.c b/arch/powerpc/lib/vmx-helper.c
index 554b248002b4f..57e897b60db86 100644
--- a/arch/powerpc/lib/vmx-helper.c
+++ b/arch/powerpc/lib/vmx-helper.c
@@ -52,7 +52,14 @@ int exit_vmx_usercopy(void)
 }
 EXPORT_SYMBOL(exit_vmx_usercopy);
 
-int enter_vmx_ops(void)
+/*
+ * Can be called from kexec copy_page() path with MMU off. The kexec
+ * code sets preempt_count to HARDIRQ_OFFSET so we return early here.
+ * Since in_interrupt() is always inline, __no_sanitize_address on this
+ * function is sufficient to avoid KASAN shadow memory accesses in real
+ * mode.
+ */
+int __no_sanitize_address enter_vmx_ops(void)
 {
 	if (in_interrupt())
 		return 0;
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec

[Sasha Levin]

From: Sourabh Jain <sourabhjain@linux.ibm.com>

[ Upstream commit 38e989d504fc52900a3786b7144fb53cd67e0389 ]

The kexec sequence invokes enter_vmx_ops() via copy_page() with the MMU
disabled. In this context, code must not rely on normal virtual address
translations or trigger page faults.

With KASAN enabled, functions get instrumented and may access shadow
memory using regular address translation. When executed with the MMU
off, this can lead to page faults (bad_page_fault) from which the
kernel cannot recover in the kexec path, resulting in a hang.

The kexec path sets preempt_count to HARDIRQ_OFFSET before entering
the MMU-off copy sequence.

current_thread_info()->preempt_count = HARDIRQ_OFFSET
  kexec_sequence(..., copy_with_mmu_off = 1)
    -> kexec_copy_flush(image)
         copy_segments()
           -> copy_page(dest, addr)
	         bl enter_vmx_ops()
                   if (in_interrupt())
                     return 0
	         beq .Lnonvmx_copy

Since kexec sets preempt_count to HARDIRQ_OFFSET, in_interrupt()
evaluates to true and enter_vmx_ops() returns early.

As in_interrupt() (and preempt_count()) are always inlined, mark
enter_vmx_ops() with __no_sanitize_address to avoid KASAN
instrumentation and shadow memory access with MMU disabled, helping
kexec boot fine with KASAN enabled.

Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Reviewed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260407124349.1698552-2-sourabhjain@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record: subsystem `powerpc/vmx`; action verb `avoid`; intent is to
prevent KASAN instrumentation of `enter_vmx_ops()` when it is reached
from the kexec MMU-off copy path.

Record: tags parsed from the candidate message:
- `Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>`
- `Reviewed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>`
- `Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>`
- `Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>`
- `Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>`
- `Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>`
- `Link: https://patch.msgid.link/20260407124349.1698552-2-
  sourabhjain@linux.ibm.com`
- No `Fixes:` tag in this commit. Absence is not a negative signal.

Record: bug description from the message: `kexec_sequence()` may call
`copy_page()` with the MMU disabled; on PowerPC Book3S this can enter
`copypage_power7.S`, which calls `enter_vmx_ops()`. If KASAN instruments
`enter_vmx_ops()`, the instrumentation may access shadow memory using
normal virtual translation, which is invalid with MMU off and can cause
an unrecoverable `bad_page_fault`/hang in kexec.

Record: hidden bug fix: yes. Although phrased as “avoid
instrumentation,” this fixes a real boot/hang failure in the kexec/kdump
path under KASAN.

## Phase 2: Diff Analysis
Record: one file changed: `arch/powerpc/lib/vmx-helper.c`, with 8
insertions and 1 deletion in the fetched v3 patch. The only functional
change is changing `int enter_vmx_ops(void)` to `int
__no_sanitize_address enter_vmx_ops(void)`; the remaining additions are
explanatory comments.

Record: modified function: `enter_vmx_ops()`.

Record: before behavior: `enter_vmx_ops()` could be KASAN-instrumented.
During kexec with MMU off, the function first checks `in_interrupt()`
and should return `0`, but KASAN prologue/body instrumentation can run
before or around normal code and touch shadow memory.

Record: after behavior: `__no_sanitize_address` suppresses KASAN
instrumentation for this function, preserving the intended early return
path when `preempt_count` contains `HARDIRQ_OFFSET`.

Record: bug category: sanitizer/real-mode correctness bug causing kexec
hang. This is a crash/hang class fix, not a cleanup.

Record: fix quality: small, surgical, and low risk. It does not alter
normal logic, public API, data structures, or userspace-visible
behavior. The only behavioral effect is disabling KASAN instrumentation
for one helper that can run in an MMU-off path.

## Phase 3: Git History Investigation
Record: local `HEAD` is a stable release commit, not the candidate. `git
log --grep` on current history, `master`, and `power-next` did not find
the candidate commit locally, so there was no commit hash available for
`b4 dig -c`.

Record: `git blame` on current `arch/powerpc/lib/vmx-helper.c` shows the
unannotated `enter_vmx_ops()` present in the local tree; due this
repository’s history shape, blame attributes the original lines to a
merge/root history point, so the exact original introduction commit was
not verifiable locally.

Record: no candidate `Fixes:` tag to follow. The companion patch in the
same series has `Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address
sanitization in kexec paths")`; `git show` confirms that commit disabled
sanitization for PowerPC kexec real-mode paths in 2022.

Record: related recent local history: `6bc9c0a905228` changed VMX
usercopy flow and added export context around the same file. That
affects hunk context for older stable trees, but not the actual one-line
fix.

Record: author context: `git log --author="Sourabh Jain" --
arch/powerpc/...` shows multiple PowerPC kexec/crash/fadump commits.
`MAINTAINERS` lists Madhavan Srinivasan and Michael Ellerman as PowerPC
maintainers; Madhavan signed off the candidate.

Record: dependencies: no source-level prerequisite for the annotation
itself. Function `enter_vmx_ops()` and `__no_sanitize_address` exist in
checked stable tags. Functional completeness is best with the companion
patch fixing `KASAN_SANITIZE_core_$(BITS).o`, because review/test
discussion says both patches together make KASAN kexec succeed.

## Phase 4: Mailing List And External Research
Record: `b4 am` for message id
`20260407124349.1698552-2-sourabhjain@linux.ibm.com` fetched a v3 two-
patch series. It reported total patches: 2, current tree apply clean,
and DKIM signature valid for patch 2.

Record: `b4 am -c` checked for newer revisions and did not report a
newer v4. v3 appears to be the latest fetched revision.

Record: `b4 mbox` fetched the v3 thread. Patch 2 was addressed to
`linuxppc-dev` and CC’d PowerPC/kexec stakeholders including Michael
Ellerman, Madhavan Srinivasan, Mahesh Salgaonkar, Hari Bathini, Daniel
Axtens, Venkat Rao Bagalkote, Aboorva Devarajan, and Ritesh Harjani.

Record: `WebFetch` of lore URLs was blocked by Anubis, but `b4` and the
`yhbt.net` lore mirror provided the thread content.

Record: v2 review discussion verified:
- Ritesh Harjani reviewed patch 2 and said “LGTM,” granting `Reviewed-
  by`.
- Aboorva Devarajan reported an actual KASAN-enabled kexec hang on
  pseries PowerVM: system reached “kexec: Starting switchover sequence”
  and then hung.
- Aboorva tested that “with both the patches applied, kexec completes
  successfully with KASAN enabled.”
- v1 annotated both `enter_vmx_ops()` and `exit_vmx_ops()`; v2 removed
  `exit_vmx_ops()` annotation and added the explanatory comment. This
  shows review-driven narrowing of the fix.

Record: stable-specific discussion: Ritesh explicitly suggested `Cc:
stable@vger.kernel.org` for patch 1. I did not find a direct stable
nomination for patch 2, but patch 2 was reviewed and tested as part of
the same two-patch functional fix.

## Phase 5: Code Semantic Analysis
Record: modified function: `enter_vmx_ops()`.

Record: callers found by exact search:
- `arch/powerpc/lib/copypage_power7.S`
- `arch/powerpc/lib/memcpy_power7.S`
- `arch/powerpc/lib/memcmp_64.S`

Record: relevant kexec call chain verified in code:
`reboot(LINUX_REBOOT_CMD_KEXEC)` -> `kernel_kexec()` ->
`machine_kexec()` -> `default_machine_kexec()` -> `kexec_sequence()` ->
`kexec_copy_flush()` -> `copy_segments()` -> `copy_page()` ->
`copypage_power7.S` -> `enter_vmx_ops()`.

Record: key callees/logic in `enter_vmx_ops()`: `in_interrupt()`,
`preempt_disable()`, and `enable_kernel_altivec()`. In the kexec MMU-off
path, `default_machine_kexec()` sets
`current_thread_info()->preempt_count = HARDIRQ_OFFSET`, and
`include/linux/preempt.h` defines `in_interrupt()` via `irq_count()`,
which observes the hardirq bits.

Record: reachability: reachable from privileged kexec/kdump paths. It is
not unprivileged-user reachable, but kdump reliability is operationally
important.

Record: similar patterns: PowerPC already disables KASAN for sensitive
real-mode/interrupt code in multiple Makefiles and uses
`__no_sanitize_address` in PowerPC interrupt/stack code, so the
attribute is consistent with local practice.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Record: buggy code exists in stable tags checked: `v5.4`, `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.18`, `v6.19`, and `v7.0` all have
`enter_vmx_ops()` without `__no_sanitize_address`.

Record: the kexec `copy_segments()` -> `copy_page()` path and
`preempt_count = HARDIRQ_OFFSET` were verified in `v5.4`, `v5.10`,
`v5.15`, `v6.1`, and current/v7.0-era code.

Record: `copypage_power7.S` calls `enter_vmx_ops()` in `v5.4`, `v5.10`,
`v5.15`, and current code.

Record: `__no_sanitize_address` exists in compiler headers in checked
stable tags, including `v5.4`, `v5.10`, `v6.1`, `v6.6`, and current.

Record: backport difficulty: clean on current `7.0.y` per `git apply
--check` and `b4`. Older stable trees may need a tiny context adjustment
because `EXPORT_SYMBOL(exit_vmx_usercopy)` is not present in older
versions, but the actual function signature is present and the backport
is straightforward.

Record: related fixes already in stable: not verified as already
present; local stable tags checked do not contain the candidate
annotation.

## Phase 7: Subsystem And Maintainer Context
Record: subsystem is PowerPC architecture library/kexec path:
`arch/powerpc/lib` and `arch/powerpc/kexec`.

Record: criticality: important/platform-specific. It affects PowerPC
systems using kexec/kdump with KASAN enabled, especially pseries/PowerVM
cases verified in review. It is not universal across all architectures.

Record: subsystem activity: local history shows recent PowerPC VMX
usercopy and kexec/crash/fadump activity, and the patch was handled
through the PowerPC maintainer path.

## Phase 8: Impact And Risk Assessment
Record: affected users: PowerPC Book3S/PowerVM-style systems using
kexec/kdump with KASAN-enabled kernels and VMX copy paths.

Record: trigger conditions: kexec/kdump switchover, MMU-off copy path,
KASAN enabled, and `copy_page()` selecting the Power7 VMX copy path. The
triggering operation is privileged, but the failure impacts crash dump
capture and reboot into the new kernel.

Record: failure mode: system hang during kexec/kdump. Review discussion
includes an observed hang after “kexec: Starting switchover sequence,”
and the commit message explains unrecoverable `bad_page_fault` risk with
MMU off. Severity: HIGH to CRITICAL for affected debug/crash-dump
deployments.

Record: benefit: high for affected PowerPC KASAN/kdump users because it
prevents a hard hang and restores kexec completion.

Record: risk: very low. One function annotation plus comment; no logic
change. The main concern is that stable maintainers should also take the
companion Makefile fix for full KASAN/kexec coverage.

## Phase 9: Final Synthesis
Record: evidence for backporting:
- Fixes a real, reviewed, and tested kexec hang with KASAN enabled.
- Aboorva Devarajan reported and tested the failure/fix.
- Ritesh Harjani reviewed the final approach.
- The fix is one function attribute and explanatory comment.
- It affects a serious operational path: kexec/kdump boot into a
  new/capture kernel.
- The buggy code and call path exist across active stable versions
  checked.
- Backport is clean for current `7.0.y` and trivial for older stable
  trees.

Record: evidence against backporting:
- The issue is config/platform specific: PowerPC plus KASAN plus
  kexec/kdump plus VMX copy path.
- Older stable trees may require minor context adjustment.
- The commit is part of a two-patch series; the companion Makefile KASAN
  fix should be included for the tested complete fix.

Record: unresolved questions:
- Exact original introduction commit for `enter_vmx_ops()` could not be
  verified from local history.
- Direct lore `WebFetch` was blocked by Anubis; I used `b4` and a lore
  mirror instead.
- I did not build-test the backport.

Stable rules checklist:
1. Obviously correct and tested: yes. The annotation directly suppresses
   KASAN instrumentation on the one helper that can execute with MMU
   off; tested-by is present.
2. Fixes a real bug: yes. Review discussion reports an actual kexec hang
   with KASAN.
3. Important issue: yes. Failure mode is kexec/kdump hang.
4. Small and contained: yes. One file, one function annotation.
5. No new features/APIs: yes.
6. Can apply to stable: yes for current `7.0.y`; older trees may need
   trivial context adjustment.

Exception category: not a device ID/quirk/build/doc exception. It is a
normal stability fix.

## Verification
- [Phase 1] Parsed the supplied commit message and fetched patch mbox;
  confirmed tags, no `Fixes:` tag in patch 2, and the linked message id.
- [Phase 2] Inspected fetched v3 diff; confirmed `arch/powerpc/lib/vmx-
  helper.c` has 8 insertions and 1 deletion, changing only
  `enter_vmx_ops()`.
- [Phase 3] Ran `git log --grep` on current history, `master`, and
  `power-next`; candidate not present locally.
- [Phase 3] Ran `git blame` around `enter_vmx_ops()`; local history
  could not identify true original introduction beyond repository
  history shape.
- [Phase 3] Ran `git show 2ab2d5794f14`; confirmed related PowerPC kexec
  KASAN sanitization commit from 2022.
- [Phase 4] Ran `b4 am` and `b4 am -c`; fetched v3 two-patch series, no
  newer revision reported, patch 2 DKIM valid.
- [Phase 4] Ran `b4 mbox`; confirmed original recipients and patch
  content.
- [Phase 4] Used lore mirror for v2 thread; confirmed Ritesh review,
  Aboorva tested-by/reported hang, and v1-to-v2 narrowing.
- [Phase 5] Searched call sites; confirmed `copypage_power7.S`,
  `memcpy_power7.S`, and `memcmp_64.S` call `enter_vmx_ops()`.
- [Phase 5] Read kexec and assembly code; confirmed kexec path reaches
  `copy_page()` with MMU-off logic and `preempt_count = HARDIRQ_OFFSET`.
- [Phase 6] Checked stable tags `v5.4` through `v7.0`; confirmed
  `enter_vmx_ops()` exists without the annotation and the relevant
  kexec/copy path exists in checked trees.
- [Phase 6] Ran `git apply --check` on current tree for patch 2 and the
  series; clean on current `7.0.y`.
- [Phase 7] Checked `MAINTAINERS`; confirmed PowerPC maintainers and
  that Madhavan Srinivasan is listed for PowerPC.
- [Phase 8] Verified failure mode from review discussion: KASAN-enabled
  kexec hangs after switchover; with both patches applied, kexec
  completes.

This should be backported, ideally together with the companion
`powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o` patch
for the tested complete KASAN/kexec fix.

**YES**

 arch/powerpc/lib/vmx-helper.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/lib/vmx-helper.c b/arch/powerpc/lib/vmx-helper.c
index 554b248002b4f..57e897b60db86 100644
--- a/arch/powerpc/lib/vmx-helper.c
+++ b/arch/powerpc/lib/vmx-helper.c
@@ -52,7 +52,14 @@ int exit_vmx_usercopy(void)
 }
 EXPORT_SYMBOL(exit_vmx_usercopy);
 
-int enter_vmx_ops(void)
+/*
+ * Can be called from kexec copy_page() path with MMU off. The kexec
+ * code sets preempt_count to HARDIRQ_OFFSET so we return early here.
+ * Since in_interrupt() is always inline, __no_sanitize_address on this
+ * function is sufficient to avoid KASAN shadow memory accesses in real
+ * mode.
+ */
+int __no_sanitize_address enter_vmx_ops(void)
 {
 	if (in_interrupt())
 		return 0;
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] powerpc/g5: Enable all windfarms by default

[Sasha Levin]

From: Linus Walleij <linusw@kernel.org>

[ Upstream commit 8d57bb61734b23f6342e9de781173f1d83f90d3a ]

The G5 defconfig is clearly intended for the G5 Powermac
series, and that should enable all the available
windfarm drivers, or the machine will overheat a short
while after booting and shut itself down, which is
annoying.

Signed-off-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260505-powermac-g5-config-v3-1-7747bf72f874@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record 1.1: Subsystem `powerpc/g5`; action verb `Enable`; intent: enable
all existing windfarm thermal drivers in `g5_defconfig`.

Record 1.2: Tags found: `Signed-off-by: Linus Walleij
<linusw@kernel.org>`, `Signed-off-by: Madhavan Srinivasan
<maddy@linux.ibm.com>`, `Link: https://patch.msgid.link/20260505-
powermac-g5-config-v3-1-7747bf72f874@kernel.org`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
stable`.

Record 1.3: The body says G5 machines using this defconfig may overheat
shortly after boot and shut down if not all windfarm drivers are
enabled. Root cause: the G5 defconfig enables some, but not all, G5
windfarm thermal control drivers.

Record 1.4: This is a hidden bug fix despite “Enable” wording: it
changes default configuration to include missing existing thermal-
management drivers, preventing hardware overheat shutdown.

## Phase 2: Diff Analysis
Record 2.1: One file changed: `arch/powerpc/configs/g5_defconfig`,
`+2/-0`. No functions modified. Scope: single-file surgical defconfig
fix.

Record 2.2: Before: `g5_defconfig` enabled `WINDFARM_PM81`, `PM91`,
`PM112`, and `PM121`, but omitted `PM72` and `RM31`. After: it also
enables `CONFIG_WINDFARM_PM72=y` and `CONFIG_WINDFARM_RM31=y`.

Record 2.3: Bug category: hardware/default-config correctness fix.
Mechanism: builds in already-existing thermal control drivers for
PowerMac7,2/7,3 and RackMac3,1 systems.

Record 2.4: Fix quality is high: two config lines, no API change, no
code refactor. Regression risk is low because the enabled drivers check
machine compatibility and return `-ENODEV` on nonmatching hardware.

## Phase 3: Git History Investigation
Record 3.1: Blame shows surrounding windfarm entries came from
`2c39bf49fd0530` in 2012, while PM72/RM31 drivers were introduced by
`6cd320996746` and are present from v3.5. Checked v3.5, v3.6, v4.0,
v5.4, v5.10: the defconfig omitted PM72/RM31.

Record 3.2: No `Fixes:` tag, so no Fixes target to follow.

Record 3.3: Recent `g5_defconfig` history is mostly defconfig
maintenance and symbol removals; no prerequisite patch was identified.
The mailed patch is a one-patch series.

Record 3.4: Linus Walleij is an established kernel
maintainer/contributor, though not listed as PowerPC maintainer. The
patch was acked by Michael Ellerman in-thread and applied by Madhavan
Srinivasan, both PowerPC maintainers per `MAINTAINERS`.

Record 3.5: Dependencies are existing Kconfig symbols and are satisfied.
`make ARCH=powerpc g5_defconfig` on the candidate produced
`CONFIG_WINDFARM_PM72=y`, `CONFIG_WINDFARM_RM31=y`, and `CONFIG_I2C=y`.

## Phase 4: Mailing List And External Research
Record 4.1: `b4 am` found the v3 submission and three revisions: v1, v2,
v3. `b4 dig` matched the patch-id and found lore/patch.msgid links.
Direct `WebFetch` to lore was blocked by Anubis, but `b4 mbox`
downloaded the full v3 thread.

Record 4.2: `b4 dig -w` showed the patch was sent to Madhavan
Srinivasan, Michael Ellerman, Nicholas Piggin, Christophe Leroy,
`linuxppc-dev`, and `linux-kernel`.

Record 4.3: No separate bug report link was present. Thread evidence
confirms impact: Segher Boessenkool wrote that affected machines boot
but “won’t run for even a minute”; Linus said Debian likely works by
having the driver in initramfs/rootfs and that built-in is safer.

Record 4.4: Series context: same two-line patch rebased from v1 to v3,
no multi-patch dependency.

Record 4.5: Web search found no stable-list discussion for this exact
patch. No known stable objection found.

## Phase 5: Code Semantic Analysis
Record 5.1: No functions changed. Relevant enabled init functions are
`wf_pm72_init()` and `wf_rm31_init()`.

Record 5.2: These init functions are run at boot/module init when built.
`windfarm_core_init()` registers the `windfarm` platform device.

Record 5.3: `wf_pm72_init()` checks `PowerMac7,2`/`PowerMac7,3`;
`wf_rm31_init()` checks `RackMac3,1`; both register a platform driver
only after compatibility checks.

Record 5.4: Reachability is boot-time on affected hardware using
`g5_defconfig`, not syscall-triggered. The failure mode is hardware
thermal shutdown, not userspace API behavior.

Record 5.5: Similar pattern already exists in the same defconfig for
other G5 windfarm drivers (`PM81`, `PM91`, `PM112`, `PM121`).

## Phase 6: Stable Tree Analysis
Record 6.1: Checked v5.10, v5.15, v6.1, v6.6, v6.12, v6.18, v6.19, and
v7.0 tags: the buggy omission exists and the PM72/RM31 Kconfig symbols
exist.

Record 6.2: Generated patch applied cleanly to all checked tags: v5.10
through v7.0.

Record 6.3: Checked those tags for the exact subject; no related fix
already present.

## Phase 7: Subsystem Context
Record 7.1: Subsystem: PowerPC defconfig / Power Macintosh thermal
management. Criticality: platform-specific but important for affected
hardware because thermal control is required for safe operation.

Record 7.2: `drivers/macintosh` has low-to-moderate activity, mostly
treewide cleanups and small fixes; PowerMac is marked orphan, while
broader PowerPC is supported.

## Phase 8: Impact And Risk
Record 8.1: Affected users: PowerMac G5 AGP systems (`PowerMac7,2`,
`PowerMac7,3`) and Xserve G5 (`RackMac3,1`) using kernels built from
`g5_defconfig`.

Record 8.2: Trigger: booting affected hardware with the default G5
config lacking the built-in thermal driver. Not unprivileged-user-
triggered.

Record 8.3: Failure mode: overheating followed by shutdown shortly after
boot. Severity: CRITICAL for affected hardware availability and hardware
safety.

Record 8.4: Benefit is high for affected stable users; risk is very low:
two defconfig lines, existing drivers, clean applies, machine-specific
init guards.

## Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: fixes real hardware thermal
shutdown; two-line contained patch; existing drivers; dependencies
verified; applies cleanly to checked stable tags; maintainer
ack/application in PowerPC fixes. Evidence against: affects only niche
old hardware; no explicit `Cc: stable` or `Tested-by`. No unresolved
technical blockers.

Record 9.2: Stable rules: obviously correct: yes; tested: config
generation verified, no runtime `Tested-by`; real bug: yes; important
issue: yes, overheating/shutdown; small/contained: yes; no new
API/features: yes, only enables existing drivers in defconfig; applies
to stable: yes for checked tags.

Record 9.3: Exception category: closest match is hardware-support/config
fix for existing drivers, not new driver code.

Record 9.4: Decision: backport. This is a small, low-risk default-config
fix for a severe hardware failure mode.

## Verification
- Phase 1: Parsed tags from supplied commit and b4-fetched mbox.
- Phase 2: Verified diff is `+2/-0` in
  `arch/powerpc/configs/g5_defconfig`.
- Phase 3: Used `git blame`, `git log`, and `git show`; found PM72/RM31
  drivers introduced by `6cd320996746`, present since v3.5.
- Phase 4: Used `b4 am`, `b4 dig`, `b4 dig -w`, `b4 mbox`; full thread
  shows Michael Ellerman ack and Madhavan Srinivasan applied it to
  `powerpc/fixes`.
- Phase 5: Read `drivers/macintosh/Kconfig`, `Makefile`,
  `windfarm_pm72.c`, `windfarm_rm31.c`, and `windfarm_core.c`; verified
  machine-specific guards and boot/init path.
- Phase 6: Checked v5.10, v5.15, v6.1, v6.6, v6.12, v6.18, v6.19, v7.0
  for symbol presence and clean patch application.
- Phase 8: Failure mode verified from commit text and mailing-list
  thread; no independent runtime test performed here.

**YES**

 arch/powerpc/configs/g5_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig
index 428f17b455132..2fe8ca266b5f6 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -85,6 +85,8 @@ CONFIG_PMAC_SMU=y
 CONFIG_MAC_EMUMOUSEBTN=y
 CONFIG_WINDFARM=y
 CONFIG_WINDFARM_PM81=y
+CONFIG_WINDFARM_PM72=y
+CONFIG_WINDFARM_RM31=y
 CONFIG_WINDFARM_PM91=y
 CONFIG_WINDFARM_PM112=y
 CONFIG_WINDFARM_PM121=y
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.1] powerpc/pasemi: Drop redundant res assignment

[Sasha Levin]

From: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

[ Upstream commit f583bd5f64d40e083dde5bb22846c4d93e59d471 ]

Return value of pas_add_bridge() is not used, so code can be simplified
to fix W=1 clang warnings:

  arch/powerpc/platforms/pasemi/pci.c:275:6: error: variable 'res' set but not used [-Werror,-Wunused-but-set-variable]

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260317130823.240279-4-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Record 1.1: Subsystem `powerpc/pasemi`; action verb `Drop`; intent is to
remove an unused local variable assignment in PA Semi PCI init.

Record 1.2: Tags found: `Signed-off-by: Krzysztof Kozlowski`, `Signed-
off-by: Madhavan Srinivasan`, `Link: https://patch.msgid.link/2026031713
0823.240279-4-krzysztof.kozlowski@oss.qualcomm.com`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
stable`.

Record 1.3: The commit explicitly describes a Clang `W=1` build warning
promoted to an error: `variable 'res' set but not used
[-Werror,-Wunused-but-set-variable]`. No runtime symptom, crash, data
corruption, or user-visible functional failure is described.

Record 1.4: This is not a hidden runtime bug fix. It is a build-warning
cleanup that can matter when building powerpc with warning-as-error
settings.

### Phase 2: Diff Analysis
Record 2.1: One file changed: `arch/powerpc/platforms/pasemi/pci.c`, `1
insertion(+), 2 deletions(-)`. Only `pas_pci_init()` is modified. Scope
is single-file surgical.

Record 2.2: Before: `pas_pci_init()` declared `int res;` and assigned
`res = pas_add_bridge(np);`, then never read `res`. After: it still
calls `pas_add_bridge(np);` but does not assign the return value. The
execution path and side effects are unchanged.

Record 2.3: Bug category: build warning/build error under specific
compiler options. Mechanism: remove unused-but-set variable. No resource
lifetime, locking, memory safety, reference counting, or logic behavior
changes.

Record 2.4: Fix quality is obviously correct by inspection: the function
call remains, only the unused local storage is removed. Regression risk
is very low because runtime behavior is unchanged.

### Phase 3: Git History Investigation
Record 3.1: `git blame` on current stable code shows the exact changed
lines are present in the checked-out stable tree. Deeper history shows
the unused `res` assignment was introduced by `250a93501d626`
(`powerpc/pasemi: Search for PCI root bus by compatible property`),
first described by `git describe` as `v4.19-rc1~110^2~83`.

Record 3.2: No `Fixes:` tag is present. Manual history identified
`250a93501d626` as the introducing commit for the exact unused
assignment pattern.

Record 3.3: Recent file history shows only the candidate commit and
unrelated treewide allocation changes in `next-20260508`; no
prerequisite pasemi PCI refactor was found.

Record 3.4: The author has other powerpc cleanup commits nearby,
including the sibling PS3 warning fix. `MAINTAINERS` identifies Madhavan
Srinivasan and Michael Ellerman as powerpc maintainers; Madhavan
committed this patch.

Record 3.5: The sibling commit `8333e4916040e` is part of the same
cleanup series but is independent. This pasemi patch applies standalone
to the current 7.0.5 checkout.

### Phase 4: Mailing List And External Research
Record 4.1: `b4 dig -c f583bd5f64d40` found the original submission by
patch-id. It found the January submission and the March resend
corresponding to the commit `Link:`. Direct WebFetch to
lore/patch.msgid.link was blocked by Anubis.

Record 4.2: `b4 dig -w` showed appropriate powerpc maintainers and
LLVM/compiler-warning stakeholders were copied: Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy, Nathan Chancellor,
LLVM list, linuxppc-dev, and others.

Record 4.3: No bug report link or reporter tag exists. The thread
describes a compiler warning/build-cleanliness issue, not a runtime bug
report.

Record 4.4: The patch is part of a two-patch series with `powerpc/ps3:
Drop redundant result assignment`; the other patch is the same class of
cleanup and is not a dependency.

Record 4.5: The downloaded thread contains no `stable` mention. A direct
lore stable search was attempted but blocked by Anubis, so no stable-
list archive result could be independently verified.

### Phase 5: Code Semantic Analysis
Record 5.1: Modified function: `pas_pci_init()`.

Record 5.2: Callers: `pas_pci_init()` is assigned to `.discover_phbs` in
the PA Semi machine descriptor in
`arch/powerpc/platforms/pasemi/setup.c`. `pas_add_bridge()` is static
and, in `next-20260508`, is called only from `pas_pci_init()`.

Record 5.3: Relevant callees in the affected path include
`pci_set_flags()`, `of_find_compatible_node()`, `pas_add_bridge()`, and
`of_node_put()`. `pas_add_bridge()` allocates/configures the PCI
controller and scans OF ranges/ISA bridge state.

Record 5.4: Reachability is boot-time/platform-init only for PA Semi
systems. It is not syscall-reachable and has no unprivileged runtime
trigger.

Record 5.5: Similar pattern found: sibling commit `8333e4916040e`
removes an unused assignment in PS3 platform code for the same warning
class.

### Phase 6: Stable Tree Analysis
Record 6.1: The exact unused `res = pas_add_bridge(np);` pattern exists
in verified tags `v4.19`, `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
`v6.17`, `v6.18`, `v6.19`, and `v7.0`. It was not present in the same
form in `v4.14` or `v4.9`.

Record 6.2: Backport difficulty is clean for the current 7.0.5 tree,
verified by `git format-patch -1 --stdout f583bd5f64d40 | git apply
--check`. Older stable trees may need minor context adjustment because
surrounding code differs in older releases.

Record 6.3: No earlier same-subject fix exists in `v7.0`; related same-
series warning fixes were found only in `next-20260508`.

### Phase 7: Subsystem Context
Record 7.1: Subsystem is `arch/powerpc/platforms/pasemi`, a platform-
specific powerpc PCI init path. Criticality is peripheral/platform-
specific, not core kernel.

Record 7.2: Recent pasemi file history is low churn. This is mature
platform code with little recent activity.

### Phase 8: Impact And Risk
Record 8.1: Affected population: PA Semi powerpc platform builders,
especially Clang `W=1` builds with powerpc `-Werror` behavior.

Record 8.2: Trigger condition is build-time only. No runtime trigger and
no unprivileged-user trigger were verified.

Record 8.3: Failure mode is build failure under specific warning/error
settings, not crash/corruption/deadlock. Severity is medium for affected
builders, low for runtime users.

Record 8.4: Benefit is narrow but real under the stable build-fix
exception. Risk is extremely low because the generated runtime behavior
should be unchanged: the same function call remains and only an unused
local assignment is removed.

### Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: fixes a verified compiler
warning/error class; code exists across many stable-era releases; patch
is tiny, standalone, and behavior-preserving; applies cleanly to current
stable checkout. Evidence against: no runtime bug, no default-build
failure was verified, no stable nomination, platform-specific impact.
Unresolved: direct stable lore search was blocked, and I did not run a
full Clang `W=1` build.

Record 9.2: Stable rules checklist: obviously correct: yes by
inspection; tested: no explicit `Tested-by` and no local full build;
fixes a real issue: yes as a build-warning/error issue under specific
settings; important: only under build-fix exception, not runtime-
critical; small/contained: yes, 3-line single-function change; no new
feature/API: yes; applies to stable: current 7.0.5 yes, older trees
likely simple but not all tested.

Record 9.3: Exception category: build fix. This is the only reason to
take it; it is not a runtime bug fix.

Record 9.4: Decision: backport as a low-risk build fix for Clang
`W=1`/powerpc warning-as-error builds. The benefit is narrow, but the
patch is minimal, standalone, and behavior-preserving.

## Verification
- [Phase 1] `git show --format=fuller --stat --patch f583bd5f64d40`
  verified commit message, tags, and exact diff.
- [Phase 2] Diff verified one file, one function, `1 insertion`, `2
  deletions`.
- [Phase 3] `git blame` and `git show 250a93501d626` verified the unused
  assignment pattern was introduced by `250a93501d626`, described as
  before `v4.19-rc1`.
- [Phase 4] `b4 dig -c`, `-a`, `-w`, and `b4 mbox` verified the patch
  submission, resend, recipients, and lack of candidate-specific stable
  tags in the downloaded thread.
- [Phase 5] `rg` and `git grep` verified `pas_pci_init()` call placement
  and `pas_add_bridge()` call sites.
- [Phase 6] `git grep` verified the pattern in `v4.19`, `v5.10`,
  `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.17`, `v6.18`, `v6.19`, and
  `v7.0`; `git apply --check` verified clean apply to current 7.0.5.
- [Phase 7] `MAINTAINERS` verified powerpc maintainers and subsystem
  ownership.
- [Phase 8] `arch/powerpc/Kconfig.debug` and `arch/powerpc/Kbuild`
  verified powerpc warning-as-error configuration exists.
- UNVERIFIED: I did not run a full Clang `W=1` build, and direct lore
  stable search was blocked by Anubis.

**YES**

 arch/powerpc/platforms/pasemi/pci.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
index 60f990a336c47..2df9552746529 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -272,13 +272,12 @@ void __init pas_pci_init(void)
 {
 	struct device_node *root = of_find_node_by_path("/");
 	struct device_node *np;
-	int res;
 
 	pci_set_flags(PCI_SCAN_ALL_PCIE_DEVS);
 
 	np = of_find_compatible_node(root, NULL, "pasemi,rootbus");
 	if (np) {
-		res = pas_add_bridge(np);
+		pas_add_bridge(np);
 		of_node_put(np);
 	}
 	of_node_put(root);
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] powerpc/pseries/htmdump: Free the global buffers in htmdump module exit

[Sasha Levin]

From: Athira Rajeev <atrajeev@linux.ibm.com>

[ Upstream commit 54d54f33813d7911555226b4220737177a2ba8d6 ]

htmdump modules uses global memory buffers to capture
details like capabilities, status of specified HTM, read the
trace buffer. These are initialized during module init and
hence needs to be freed in module exit.

Patch adds freeing of the memory in module exit. The change
also includes minor clean up for the variable name. The
read call back for the debugfs interface file saves filp->private_data
to local variable name which is same as global variable
name for the memory buffers. Rename these local variable
names.

Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260314132432.25581-1-atrajeev@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Summary
This commit fixes a real resource leak in
`arch/powerpc/platforms/pseries/htmdump.c`: `htm_status_buf`,
`htm_info_buf`, and `htm_caps_buf` are each allocated with
`kmalloc(PAGE_SIZE, GFP_KERNEL)` during module/debugfs initialization,
but only `htm_buf` is freed in `htmdump_exit()`. The patch adds the
three missing `kfree()` calls. The local-variable renames are cleanup
and are also used by the following two patches in the same posted
series.

The benefit is modest because the leak is on module unload, not a hot
path, and the feature is PowerPC pseries/debugfs-specific. But it is a
real leak in a `default m` module, the fix is trivial, isolated, and low
risk. For stable trees that contain the v6.16-era `htmstatus`,
`htminfo`, and `htmcaps` additions, this is suitable.

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record 1.1: Subsystem is `powerpc/pseries/htmdump`; action verb is
`Free`; claimed intent is freeing global HTM debugfs buffers during
module exit.

Record 1.2: Tags in the supplied commit message: `Signed-off-by: Athira
Rajeev <atrajeev@linux.ibm.com>`, `Signed-off-by: Madhavan Srinivasan
<maddy@linux.ibm.com>`, `Link:
https://patch.msgid.link/20260314132432.25581-1-atrajeev@linux.ibm.com`.
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
or `Cc: stable@vger.kernel.org` tag was present in this commit.

Record 1.3: The body describes global memory buffers initialized in
module init and not freed in module exit. The user-visible symptom is
unreclaimed kernel memory after unloading the module. No crash, stack
trace, reporter, affected-version statement, or reproducer is given.

Record 1.4: This is a hidden cleanup-style bug fix: the functional
change is missing resource release on module exit.

### Phase 2: Diff Analysis
Record 2.1: One file changed:
`arch/powerpc/platforms/pseries/htmdump.c`, 17 insertions and 14
deletions in the posted patch. Modified functions are `htmdump_read()`,
`htmstatus_read()`, `htminfo_read()`, `htmcaps_read()`, and
`htmdump_exit()`. Scope is single-file surgical.

Record 2.2: The read-callback hunks rename local variables from names
shadowing globals to `*_data`; behavior is unchanged. The exit hunk
changes `htmdump_exit()` from freeing only `htm_buf` to freeing
`htm_buf`, `htm_status_buf`, `htm_info_buf`, and `htm_caps_buf`.

Record 2.3: Bug category is resource leak. Verified allocations are
three `PAGE_SIZE` buffers for status/info/caps in
`htmdump_init_debugfs()` without corresponding frees before this patch.

Record 2.4: Fix quality is high: `kfree(NULL)` is safe, the buffers are
global module-owned allocations, and debugfs removal already happens
before freeing. Regression risk is very low. The only non-functional
churn is local-variable rename.

### Phase 3: Git History Investigation
Record 3.1: `git blame` on the current stable checkout points the
relevant lines at the repository boundary merge `f3f5edc5e41e0`, so I
followed explicit commit objects. `htm_status_buf` was added by
`627cf584f4c3`, `htm_info_buf` by `dea7384e14e7`, and `htm_caps_buf` by
`143a2584627c`, all described by `git describe --contains`/history as
v6.16-rc1-era commits.

Record 3.2: Candidate has no `Fixes:` tag, so no direct Fixes target
applies. Related series patches 2/3 and 3/3 have `Fixes:` tags for
`dea7384e14e7` and `627cf584f4c3`, but this patch does not depend on
those fixes.

Record 3.3: Recent `htmdump` history shows the v6.16 additions for
status/info/setup/flags/caps and a header include fix. The candidate is
patch 1/3 in a series; patch 1 is standalone, while patches 2/3 and 3/3
textually build on its variable renames.

Record 3.4: Author Athira Rajeev authored the original htmdump expansion
commits; Madhavan Srinivasan committed them. This was verified from `git
show` for the status/info/caps commits.

Record 3.5: No prerequisite is needed for patch 1 beyond the buffers
existing. An isolated `git apply --check` of patch 1 succeeds on the
current 7.0 stable checkout.

### Phase 4: Mailing List And External Research
Record 4.1: `b4 dig` could not be meaningfully run because the candidate
commit object/hash is not present in the checked-out refs; `b4 dig -h`
confirmed it requires `-c <commitish>`. I used `b4 mbox -c` with
message-id `20260314132432.25581-1-atrajeev@linux.ibm.com`; it fetched a
3-message thread and reported no newer revision.

Record 4.2: Original recipients from the mbox were
`maddy@linux.ibm.com`, `linuxppc-dev@lists.ozlabs.org`, and CCs
including `hbathini`, `sshegde`, and IBM HTM-related recipients. No
review replies, NAKs, or stable nominations were present in the fetched
mbox.

Record 4.3: No `Reported-by` or bug-report link exists for this
candidate. `WebFetch` to lore/patch.msgid was blocked by Anubis, but `b4
mbox` successfully fetched the thread.

Record 4.4: The patch is part of a 3-patch series. Patch 1 fixes exit
cleanup; patch 2 fixes `htminfo_read()` offset handling; patch 3 fixes
`htmstatus_read()` offset handling. Patch 1 can apply standalone, and
later patches depend textually on its renames.

Record 4.5: Stable-specific lore WebFetch was blocked by Anubis.
WebSearch for the exact subject and stable context found no specific
stable discussion. Local `git log --grep` checks of `v6.18`, `v6.19`,
`v7.0`, and `linux-rolling-stable` found no exact-subject match.

### Phase 5: Code Semantic Analysis
Record 5.1: Modified functions are `htmdump_read()`, `htmstatus_read()`,
`htminfo_read()`, `htmcaps_read()`, and `htmdump_exit()`.

Record 5.2: Callers/entry points are verified through file operations
and module macros: `htmdump_exit()` is registered with `module_exit()`,
reads are reached through debugfs files created by
`debugfs_create_file()` with the corresponding fops.

Record 5.3: Key callees are `debugfs_remove_recursive()`, `kfree()`,
`htm_hcall_wrapper()`, `virt_to_phys()`, and
`simple_read_from_buffer()`. The functional fix only adds `kfree()`
calls in exit.

Record 5.4: Reachability is module lifecycle and debugfs based. The leak
triggers on module unload after successful allocation of the
status/info/caps buffers. Unprivileged triggering was not verified and
is not relied on; Kconfig shows `HTMDUMP` is `tristate`, `default m`,
and depends on `PPC_PSERIES && DEBUG_FS`.

Record 5.5: Similar pattern found: `htm_buf` was already freed in
`htmdump_exit()`, while the three later-added global buffers were not.

### Phase 6: Stable Tree Analysis
Record 6.1: `v6.15` has `htmdump.c` with only `htm_buf`; `v6.16`,
`v6.17`, `v6.18`, `v6.19`, and `v7.0` have the three additional buffers
and only free `htm_buf`. So the bug affects stable trees containing the
v6.16 htmdump expansions, not older trees lacking those buffers.

Record 6.2: Backport difficulty is low for affected trees. The patch’s
base blob matches `v6.16`/`v6.17`/current 7.0 content for the relevant
file, and isolated patch 1 applies cleanly to the current checkout.

Record 6.3: No exact-subject related fix was found in checked `v6.18`,
`v6.19`, `v7.0`, or `linux-rolling-stable`.

### Phase 7: Subsystem And Maintainer Context
Record 7.1: Subsystem is PowerPC pseries platform driver/debugfs
support. Criticality is peripheral/platform-specific, not core kernel-
wide.

Record 7.2: `git log -20 v7.0 -- arch/powerpc/platforms/pseries` shows
active pseries development, but this particular fix is contained to
`htmdump.c`.

### Phase 8: Impact And Risk
Record 8.1: Affected users are PowerPC pseries users with
`CONFIG_HTMDUMP` enabled, primarily using the debugfs HTM dump module.

Record 8.2: Trigger is successful module initialization followed by
module exit/unload. Repeated load/unload can accumulate unreclaimed
pages until reboot. This is not verified as unprivileged-triggerable.

Record 8.3: Failure mode is kernel memory/resource leak, three
`PAGE_SIZE` allocations per unload for the later buffers. Severity is
medium: real and persistent until reboot, but not a crash/security/data-
corruption fix and not a hot path.

Record 8.4: Benefit is moderate for affected stable users; risk is very
low because the functional change is only three `kfree()` calls after
debugfs removal.

### Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: real resource leak, affects stable
trees v6.16 and newer that contain the expanded htmdump module, fix is
tiny and obviously correct, isolated patch applies cleanly. Evidence
against: peripheral platform-specific module, leak occurs on module
unload rather than common runtime path, no reporter/testing/stable tags
in this patch. Unresolved: no full lore review discussion was available
beyond the 3-patch mbox; direct WebFetch lore pages were blocked.

Record 9.2: Stable rules checklist: obviously correct yes; fixes a real
bug yes; important enough is borderline but acceptable as a real
resource leak with very low regression risk; small and contained yes; no
new feature/API yes; applies to affected stable trees yes for current
7.0 and likely cleanly where file matches v6.16+.

Record 9.3: No automatic exception category applies: this is not a
device ID, quirk, DT update, build fix, or documentation-only fix.

Record 9.4: Decision is YES for stable trees that contain
`htm_status_buf`, `htm_info_buf`, and `htm_caps_buf`.

## Verification
- Phase 1: Parsed supplied commit message and b4-fetched patch 1;
  confirmed no `Fixes:`, `Reported-by`, `Tested-by`, review, or stable
  tag in patch 1.
- Phase 2: Read `arch/powerpc/platforms/pseries/htmdump.c`; confirmed
  allocations and missing frees; inspected patch hunks from
  `/tmp/htmdump-20260314.mbx`.
- Phase 3: Ran `git blame -L 410,485`; followed explicit commits
  `627cf584f4c3`, `dea7384e14e7`, and `143a2584627c` with `git show`;
  checked author/subsystem history.
- Phase 4: `b4 mbox -c` fetched the 3-message thread; direct `WebFetch`
  lore URLs were blocked; WebSearch found no exact stable discussion.
- Phase 5: Used `rg`, `ReadFile`, and Kconfig/Makefile/docs to verify
  module/debugfs reachability and `CONFIG_HTMDUMP` as `tristate`,
  `default m`.
- Phase 6: Checked `v6.15`, `v6.16`, `v6.17`, `v6.18`, `v6.19`, and
  `v7.0` file contents; isolated patch 1 passed `git apply --check`.
- Phase 8: Verified failure mode from concrete `kmalloc(PAGE_SIZE)`
  allocations and missing matching `kfree()` calls.
- Unverified: whether every downstream stable branch has identical
  context; direct stable-list lore search was blocked by Anubis.

**YES**

 arch/powerpc/platforms/pseries/htmdump.c | 31 +++++++++++++-----------
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/htmdump.c b/arch/powerpc/platforms/pseries/htmdump.c
index 742ec52c9d4df..93f0cc2dc7fb6 100644
--- a/arch/powerpc/platforms/pseries/htmdump.c
+++ b/arch/powerpc/platforms/pseries/htmdump.c
@@ -86,7 +86,7 @@ static ssize_t htm_return_check(long rc)
 static ssize_t htmdump_read(struct file *filp, char __user *ubuf,
 			     size_t count, loff_t *ppos)
 {
-	void *htm_buf = filp->private_data;
+	void *htm_buf_data = filp->private_data;
 	unsigned long page, read_size, available;
 	loff_t offset;
 	long rc, ret;
@@ -100,7 +100,7 @@ static ssize_t htmdump_read(struct file *filp, char __user *ubuf,
 	 * - last three values are address, size and offset
 	 */
 	rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
-				   htmtype, H_HTM_OP_DUMP_DATA, virt_to_phys(htm_buf),
+				   htmtype, H_HTM_OP_DUMP_DATA, virt_to_phys(htm_buf_data),
 				   PAGE_SIZE, page);
 
 	ret = htm_return_check(rc);
@@ -112,7 +112,7 @@ static ssize_t htmdump_read(struct file *filp, char __user *ubuf,
 	available = PAGE_SIZE;
 	read_size = min(count, available);
 	*ppos += read_size;
-	return simple_read_from_buffer(ubuf, count, &offset, htm_buf, available);
+	return simple_read_from_buffer(ubuf, count, &offset, htm_buf_data, available);
 }
 
 static const struct file_operations htmdump_fops = {
@@ -226,7 +226,7 @@ static int htmstart_get(void *data, u64 *val)
 static ssize_t htmstatus_read(struct file *filp, char __user *ubuf,
 			     size_t count, loff_t *ppos)
 {
-	void *htm_status_buf = filp->private_data;
+	void *htm_status_data = filp->private_data;
 	long rc, ret;
 	u64 *num_entries;
 	u64 to_copy;
@@ -238,7 +238,7 @@ static ssize_t htmstatus_read(struct file *filp, char __user *ubuf,
 	 * - last three values as addr, size and offset
 	 */
 	rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
-				   htmtype, H_HTM_OP_STATUS, virt_to_phys(htm_status_buf),
+				   htmtype, H_HTM_OP_STATUS, virt_to_phys(htm_status_data),
 				   PAGE_SIZE, 0);
 
 	ret = htm_return_check(rc);
@@ -255,13 +255,13 @@ static ssize_t htmstatus_read(struct file *filp, char __user *ubuf,
 	 * So total count to copy is:
 	 * 32 bytes (for first 7 fields) + (number of HTM entries * entry size)
 	 */
-	num_entries = htm_status_buf + 0x10;
+	num_entries = htm_status_data + 0x10;
 	if (htmtype == 0x2)
 		htmstatus_flag = 0x8;
 	else
 		htmstatus_flag = 0x6;
 	to_copy = 32 + (be64_to_cpu(*num_entries) * htmstatus_flag);
-	return simple_read_from_buffer(ubuf, count, ppos, htm_status_buf, to_copy);
+	return simple_read_from_buffer(ubuf, count, ppos, htm_status_data, to_copy);
 }
 
 static const struct file_operations htmstatus_fops = {
@@ -273,7 +273,7 @@ static const struct file_operations htmstatus_fops = {
 static ssize_t htminfo_read(struct file *filp, char __user *ubuf,
 			     size_t count, loff_t *ppos)
 {
-	void *htm_info_buf = filp->private_data;
+	void *htm_info_data = filp->private_data;
 	long rc, ret;
 	u64 *num_entries;
 	u64 to_copy;
@@ -284,7 +284,7 @@ static ssize_t htminfo_read(struct file *filp, char __user *ubuf,
 	 * - last three values as addr, size and offset
 	 */
 	rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
-				   htmtype, H_HTM_OP_DUMP_SYSPROC_CONF, virt_to_phys(htm_info_buf),
+				   htmtype, H_HTM_OP_DUMP_SYSPROC_CONF, virt_to_phys(htm_info_data),
 				   PAGE_SIZE, 0);
 
 	ret = htm_return_check(rc);
@@ -301,15 +301,15 @@ static ssize_t htminfo_read(struct file *filp, char __user *ubuf,
 	 * So total count to copy is:
 	 * 32 bytes (for first 5 fields) + (number of HTM entries * entry size)
 	 */
-	num_entries = htm_info_buf + 0x10;
+	num_entries = htm_info_data + 0x10;
 	to_copy = 32 + (be64_to_cpu(*num_entries) * 16);
-	return simple_read_from_buffer(ubuf, count, ppos, htm_info_buf, to_copy);
+	return simple_read_from_buffer(ubuf, count, ppos, htm_info_data, to_copy);
 }
 
 static ssize_t htmcaps_read(struct file *filp, char __user *ubuf,
 			     size_t count, loff_t *ppos)
 {
-	void *htm_caps_buf = filp->private_data;
+	void *htm_caps_data = filp->private_data;
 	long rc, ret;
 
 	/*
@@ -319,7 +319,7 @@ static ssize_t htmcaps_read(struct file *filp, char __user *ubuf,
 	 *   and zero
 	 */
 	rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
-				   htmtype, H_HTM_OP_CAPABILITIES, virt_to_phys(htm_caps_buf),
+				   htmtype, H_HTM_OP_CAPABILITIES, virt_to_phys(htm_caps_data),
 				   0x80, 0);
 
 	ret = htm_return_check(rc);
@@ -328,7 +328,7 @@ static ssize_t htmcaps_read(struct file *filp, char __user *ubuf,
 		return ret;
 	}
 
-	return simple_read_from_buffer(ubuf, count, ppos, htm_caps_buf, 0x80);
+	return simple_read_from_buffer(ubuf, count, ppos, htm_caps_data, 0x80);
 }
 
 static const struct file_operations htminfo_fops = {
@@ -482,6 +482,9 @@ static void __exit htmdump_exit(void)
 {
 	debugfs_remove_recursive(htmdump_debugfs_dir);
 	kfree(htm_buf);
+	kfree(htm_status_buf);
+	kfree(htm_info_buf);
+	kfree(htm_caps_buf);
 }
 
 module_init(htmdump_init);
-- 
2.53.0