[PATCH AUTOSEL 6.18-5.10] s390/zcore: Removed unused variables

[PATCH AUTOSEL 6.18-5.10] s390/zcore: Removed unused variables

[Sasha Levin]

From: Heiko Carstens <hca@linux.ibm.com>

[ Upstream commit 0a2aa995c0a1d363b5f0803862e84834e3876ae2 ]

allmodconfig with clang W=1 points out unused global variables:

drivers/s390/char/zcore.c:49:23: error: variable
 'zcore_reipl_file' set but not used [-Werror,-Wunused-but-set-global]
drivers/s390/char/zcore.c:50:23: error: variable
 'zcore_hsa_file' set but not used [-Werror,-Wunused-but-set-global]

Remove both of them, since there is no point in keeping them.

Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `s390/zcore: Removed unused variables`

**Local tree:** Linux **6.18.44** (`stable/linux-6.18.y`, `git describe
HEAD` → `v6.18.44`)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
**Record:** `[s390/zcore]` `[Removed]` — removes two unused static
`struct dentry *` globals in the zcore crash-dump driver.

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
**Record:**
- **Reviewed-by:** Christian Borntraeger `<borntraeger@linux.ibm.com>`
  (s390 maintainer)
- **Signed-off-by:** Heiko Carstens `<hca@linux.ibm.com>` (s390
  maintainer)
- **Signed-off-by:** Alexander Gordeev `<agordeev@linux.ibm.com>`
- No Fixes:, Reported-by:, Tested-by:, Link:, Cc: stable tags
- Notable: no syzbot, no user bug report — build-time issue only

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
**Record:**
- **Bug:** `allmodconfig` with **clang** and **W=1** treats
  `zcore_reipl_file` and `zcore_hsa_file` as `-Werror,-Wunused-but-set-
  global` errors.
- **Symptom:** compilation failure (not a runtime failure).
- **Root cause (author):** globals are assigned from
  `debugfs_create_file()` but never read afterward; no reason to keep
  them.
- **Version info:** none stated; failure requires clang + W=1 (+
  typically W=e or CONFIG_WERROR for `-Werror`).

### Step 1.4: DETECT HIDDEN BUG FIXES
**Record:** Not a hidden runtime fix. This is an explicit **build-fix /
warning cleanup**. The variables became dead when debugfs return-value
checking was removed upstream in `7449ca87312a5` ("s390/zcore: no need
to check return value of debugfs_create functions", 2021), which dropped
the only uses of these pointers beyond assignment.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
**Record:**
- **File:** `drivers/s390/char/zcore.c` only (+2 / −6 lines)
- **Functions:** `zcore_init()` (init path only)
- **Scope:** single-file surgical change

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Record:**
- **Hunk 1 (globals):** Removes `static struct dentry *zcore_reipl_file`
  and `zcore_hsa_file` declarations.
- **Hunk 2 (`zcore_init`):** Before: assign return values of
  `debugfs_create_file()` to globals. After: call
  `debugfs_create_file()` directly without storing results.
- **Behavior:** debugfs files `reipl` and `hsa` are still created
  identically; only the unused storage is removed.

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Record:** **Build / compiler-warning category.** With `W=1`, the
kernel stops suppressing `-Wno-unused-but-set-variable` (see
`scripts/Makefile.extrawarn`). Clang reports globals as `-Wunused-but-
set-global`. With `W=e` or `CONFIG_WERROR`, this becomes a hard error.
No runtime bug (no UAF, leak, race, or NULL deref).

### Step 2.4: ASSESS THE FIX QUALITY
**Record:** Obviously correct — the pointers were never read after
assignment, and `zcore.c` has no `debugfs_remove` or `__exit` path that
would need them. Minimal diff, zero functional change. Regression risk:
**very low**.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
**Record:** Lines 50–51 and 357–360 in current tree trace to
`e664048784506` (v6.18 import). Variables originally added for debugfs
error handling (`099b765139929`, `b4b3d128c821d`) and became unused when
return-value checks were removed in `7449ca87312a5` (2021).

### Step 3.2: FOLLOW THE FIXES: TAG
**Record:** N/A — no Fixes: tag.

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
**Record:** Upstream fix: `0a2aa995c0a1d363b5f0803862e84834e3876ae2`.
Stable-queue copy: `423880f00db3d`. Fix is **not** in current HEAD
(`merge-base --is-ancestor` → exit 1). Master already has the fix (no
`zcore_reipl_file` on `master`). Standalone one-commit fix, not part of
a series.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
**Record:** Heiko Carstens is s390 maintainer. Recent s390 stable
commits on this tree are security/crash fixes (zcrypt, dasd, qeth). This
is a lower-severity build hygiene fix from the same subsystem.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
**Record:** No dependencies. Patch applies cleanly (`git show
423880f00db3d | patch --dry-run` succeeded). No new APIs or structures
assumed.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
**Record:** `b4 dig -c 0a2aa995c0a1d363b5f0803862e84834e3876ae2` — **no
lore match found**. Likely committed directly to s390 tree without a
searchable lore thread.

### Step 4.2: CHECK WHO REVIEWED THE PATCH
**Record:** Reviewed-by Christian Borntraeger (s390 co-maintainer). b4
dig -w not available due to no lore match.

### Step 4.3: SEARCH FOR THE BUG REPORT
**Record:** N/A — no Reported-by or Link tags. Failure mode documented
only in commit message (clang W=1 allmodconfig).

### Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
**Record:** Standalone. Related historical commit `7449ca87312a5`
introduced the dead assignments; that behavioral change is already
present in this tree's `zcore.c`.

### Step 4.5: CHECK STABLE MAILING LIST HISTORY
**Record:** Not searched individually; however, this **same stable
tree** already contains analogous W=1 clang build fixes (see Phase 8).

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
**Record:** `zcore_init()` only.

### Step 5.2: TRACE CALLERS
**Record:** `zcore_init` registered via `subsys_initcall(zcore_init)` —
runs once at boot on s390 when `CONFIG_CRASH_DUMP` is enabled
(`drivers/s390/char/Makefile`: `obj-$(CONFIG_CRASH_DUMP) += zcore.o`).

### Step 5.3: TRACE CALLEES
**Record:** `debugfs_create_dir()`, `debugfs_create_file()` — creates
debugfs nodes for crash-dump tooling. Return values were stored but
never used for cleanup or error handling.

### Step 5.4: FOLLOW THE CALL CHAIN
**Record:** Init-only path at boot. Not reachable from userspace
syscalls. Bug trigger is **compile-time** when building the driver
object, not at runtime.

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
**Record:** Same pattern fixed on this stable tree for other drivers —
e.g. `4a894ba48fa51` (matroxfb, "Mark variable with __maybe_unused to
avoid W=1 build break"), `433bb1344ef66` (nfsd), `248e4b9cc719f`
(nfs/blocklayout, "Fix compilation error (`make W=1`)").

---

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

### Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
**Record:** **YES.** `drivers/s390/char/zcore.c` lines 50–51 and 357–360
still declare and assign `zcore_reipl_file` / `zcore_hsa_file`. Dead-
assignment state present since the 2021 debugfs cleanup; clang W=1
exposure is newer.

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
**Record:** **Clean apply** expected — file matches upstream pre-fix
content. No recent churn on `zcore.c` in 6.18.y (only `e664048784506`
import + unrelated s390 char commits elsewhere).

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
**Record:** Fix **not** present in HEAD. No alternate fix found via grep
or log.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
**Record:** **s390/char/zcore** — platform-specific crash-dump support.
**Criticality: PERIPHERAL** (s390-only, CONFIG_CRASH_DUMP). Important
for IBM/mainframe crash-dump workflows but not universal.

### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
**Record:** s390 subtree on 6.18.y is active (zcrypt security fixes,
dasd, qeth, monwriter). zcore.c itself is stable/unchanged since branch.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
**Record:** **Config-specific:** s390 builders using
`CONFIG_CRASH_DUMP=y`, **clang**, and **W=1** (often with
W=e/CONFIG_WERROR). Not affected: default gcc builds, prebuilt distro
kernels, non-s390 arches.

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
**Record:** `make W=1` (or W=1e) + clang + allmodconfig (or any config
enabling zcore). Unprivileged users cannot trigger at runtime. Trigger
is **developer/CI build configuration** — uncommon but real for kernel
CI and s390 maintainers.

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
**Record:** **Compilation error** — severity **MEDIUM** for stable rules
(build fix, not crash/corruption/security). Severity **LOW** for end
users running shipped kernels.

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
**Record:**
- **Benefit:** Unblocks clang W=1 allmodconfig builds on s390; aligns
  with existing 6.18.y precedent for identical W=1 fixes.
- **Risk:** Minimal — removes dead code only.
- **Ratio:** Favorable for backport given precedent and zero runtime
  impact.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backport:**
- Genuine build failure under documented kernel build flags (clang W=1)
- Build-fix exception category in stable rules
- Tiny, maintainer-reviewed, obviously correct
- Applies cleanly; buggy code confirmed in 6.18.44
- **Precedent on this tree:** `4a894ba48fa51`, `433bb1344ef66`,
  `248e4b9cc719f` — same class of W=1 clang fix already backported to
  `stable/linux-6.18.y`
- No functional change to debugfs behavior

**AGAINST backport:**
- No runtime bug; default builds unaffected
- Narrow audience (s390 + CONFIG_CRASH_DUMP + clang W=1)
- Variables unused since 2021 without widespread reports
- No lore discussion or explicit stable nomination found

**UNRESOLVED:**
- b4 dig found no mailing-list thread (patch likely landed via s390 tree
  directly)

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — trivial dead-code removal;
   Reviewed-by s390 maintainer.
2. Fixes a real bug affecting users? **PASS** — real compile failure for
   s390 clang W=1 builders.
3. Important issue? **PASS (borderline)** — build fix, not
   crash/security; MEDIUM severity.
4. Small and contained? **PASS** — 8 lines, one file.
5. No new features or APIs? **PASS** — pure cleanup.
6. Can apply to the local tree? **PASS** — code present; dry-run apply
   succeeded.

### Step 9.3: EXCEPTION CATEGORIES
**Record:** **Build fix** — fixes compilation error with clang W=1 on
s390.

### Step 9.4: DECISION RATIONALE

For **Linux 6.18.y**, this commit should be backported. The fix is
surgical, risk-free, and addresses a reproducible build break under
`make W=1` with clang — the same class of issue already accepted on this
stable branch (matroxfb, nfsd, nfs/blocklayout). While end users of
prebuilt kernels are unaffected, kernel builders and CI on s390 are
blocked without it, and stable policy explicitly includes build fixes.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body from user-provided commit and
  `git show 423880f00db3d` / `git show 0a2aa995c0a1`
- **[Phase 2]** Read diff; confirmed 2 insertions, 6 deletions in
  `zcore.c`; analyzed `zcore_init()` only
- **[Phase 3]** `git describe HEAD` → v6.18.44; `git blame` on lines
  49–52, 355–362; `git log -S zcore_reipl_file` found introduction
  history via `7449ca87312a5`, `b4b3d128c821d`, `099b765139929`; `merge-
  base --is-ancestor 423880f00db3d HEAD` → not in tree;
  `master:drivers/s390/char/zcore.c` has fix applied
- **[Phase 4]** `b4 dig -c 0a2aa995` → no lore match; `b4 dig -c
  423880f00db3d` → no lore match
- **[Phase 5]** Read `zcore.c`; `grep` callers — `subsys_initcall` only;
  `grep debugfs_remove` → none; Makefile: `obj-$(CONFIG_CRASH_DUMP) +=
  zcore.o`
- **[Phase 6]** `grep zcore_reipl_file` in tree → present; `git show
  423880f00db3d | patch --dry-run` → applies cleanly
- **[Phase 7]** `git log stable/linux-6.18.y -15 -- drivers/s390/` —
  active s390 stable maintenance
- **[Phase 8]** Read `scripts/Makefile.extrawarn` lines 108–130 (W=1
  enables unused-but-set warnings); `git log stable/linux-6.18.y
  --grep=W=1` found precedent commits `4a894ba48fa51`, `433bb1344ef66`,
  `248e4b9cc719f`; `git show 4a894ba48fa51` — identical W=1 clang build-
  break pattern
- **[Phase 9]** Synthesis and checklist completed from verified evidence
  above

**YES**The background check finished: commit `423880f00db3d` is **not**
in the current `stable/linux-6.18.y` tree (ancestor check exit code 1).
The unused `zcore_reipl_file` / `zcore_hsa_file` globals are still
present in `drivers/s390/char/zcore.c` at v6.18.44.

**Verdict unchanged:** backport **YES** — small clang `W=1` build fix,
applies cleanly, matches similar W=1 fixes already on this stable
branch.

 drivers/s390/char/zcore.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/s390/char/zcore.c b/drivers/s390/char/zcore.c
index 33cebb91b9338..e74f41f201099 100644
--- a/drivers/s390/char/zcore.c
+++ b/drivers/s390/char/zcore.c
@@ -47,8 +47,6 @@ struct ipib_info {
 static struct debug_info *zcore_dbf;
 static int hsa_available;
 static struct dentry *zcore_dir;
-static struct dentry *zcore_reipl_file;
-static struct dentry *zcore_hsa_file;
 static struct ipl_parameter_block *zcore_ipl_block;
 static unsigned long os_info_flags;
 
@@ -354,10 +352,8 @@ static int __init zcore_init(void)
 		goto fail;
 
 	zcore_dir = debugfs_create_dir("zcore" , NULL);
-	zcore_reipl_file = debugfs_create_file("reipl", S_IRUSR, zcore_dir,
-						NULL, &zcore_reipl_fops);
-	zcore_hsa_file = debugfs_create_file("hsa", S_IRUSR|S_IWUSR, zcore_dir,
-					     NULL, &zcore_hsa_fops);
+	debugfs_create_file("reipl", S_IRUSR, zcore_dir, NULL, &zcore_reipl_fops);
+	debugfs_create_file("hsa", S_IRUSR|S_IWUSR, zcore_dir, NULL, &zcore_hsa_fops);
 
 	register_reboot_notifier(&zcore_reboot_notifier);
 	atomic_notifier_chain_register(&panic_notifier_list, &zcore_on_panic_notifier);
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] s390/zcore: Removed unused variables

[sashiko-bot]

> From: Heiko Carstens <hca@linux.ibm.com>
> 
> [ Upstream commit 0a2aa995c0a1d363b5f0803862e84834e3876ae2 ]
> 
> allmodconfig with clang W=1 points out unused global variables:
> 
> drivers/s390/char/zcore.c:49:23: error: variable
>  'zcore_reipl_file' set but not used [-Werror,-Wunused-but-set-global]
> drivers/s390/char/zcore.c:50:23: error: variable
>  'zcore_hsa_file' set but not used [-Werror,-Wunused-but-set-global]
> 
> Remove both of them, since there is no point in keeping them.
> 
> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-294-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18-5.15] s390/cio: Purge based on the cdev's online status

[Sasha Levin]

From: Vineeth Vijayan <vneethv@linux.ibm.com>

[ Upstream commit 58d50cad63e85daae032924ecc3d457fb1ec02fb ]

Ensure that all devices currently offline are purged correctly.

Previously, purging logic relied on the internal FSM state to
determine whether a device was offline. However, devices with a
target state of offline could be skipped if CIO internal
processing was still ongoing during the purge operation.

Update the purge decision logic to rely on the online variable
in the cdev structure instead of the internal FSM state,
providing a more reliable indication of actual device
availability.

Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
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:** `[s390/cio]` `[Purge]` — Change purge eligibility to use the
cdev's `online` flag instead of internal FSM state.

### Step 1.2: Commit Message Tags
**Record:**
- **Fixes:** — none
- **Reported-by:** — none
- **Tested-by:** — none
- **Reviewed-by:** Peter Oberparleiter `<oberpar@linux.ibm.com>`
  (s390/cio maintainer)
- **Acked-by:** — none
- **Link:** — none
- **Cc: stable:** — none (expected for this review pipeline)
- **Signed-off-by:** Vineeth Vijayan, Alexander Gordeev (ignore
  pipeline-added SOBs)

Notable: maintainer review, no fuzzer/user bug report.

### Step 1.3: Commit Body Analysis
**Record:**
- **Bug:** `purge_fn()` used `cdev->private->state == DEV_STATE_OFFLINE`
  to decide purge eligibility. Devices targeted for offline can still be
  in transitional FSM states during CIO processing, so purge skips them.
- **Symptom:** `echo purge > /proc/cio_ignore` does not remove all
  blacklisted, offline devices.
- **Root cause:** FSM state lags behind the user-visible offline state;
  `cdev->online` is cleared earlier and is the authoritative "in use"
  indicator.
- **Version info:** none in message.

### Step 1.4: Hidden Bug Fix Detection
**Record:** Yes — described as a purge correctness fix, not cosmetic
cleanup. It fixes incorrect device-unregistration behavior in an admin
path.

---

## Phase 2: Diff Analysis

### Step 2.1: Change Inventory
**Record:**
- **Files:** `drivers/s390/cio/device.c` (+1/−1 effective logic line)
- **Function:** `purge_fn()`
- **Scope:** Single-file, surgical fix

### Step 2.2: Code Flow Change
**Record:**
- **Before:** If cdev exists and `state != DEV_STATE_OFFLINE`, skip
  purge (`goto unlock`).
- **After:** If cdev exists and `cdev->online`, skip purge.
- **Path affected:** `/proc/cio_ignore` purge via
  `ccw_purge_blacklisted()` → `purge_fn()`.

### Step 2.3: Bug Mechanism
**Record:** **Logic/correctness fix.** Purge used internal FSM state
instead of the user-visible online flag.

In `ccw_device_set_offline()`, `cdev->online = 0` is set at line 289
before FSM reaches `DEV_STATE_OFFLINE`. During that window, old logic
incorrectly skips purge. The same applies to other non-OFFLINE FSM
states (e.g. `DEV_STATE_BOXED`, `DEV_STATE_NOT_OPER`) where `online ==
0` but state ≠ `DEV_STATE_OFFLINE`.

### Step 2.4: Fix Quality
**Record:** Obviously correct and minimal. Aligns with kernel docs and
`sch_get_action()` (line 1443), which also keys off `cdev->online`.
Protected by existing `onoff` atomic during online/offline sysfs ops.
Very low regression risk.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:** `purge_fn()` and the `DEV_STATE_OFFLINE` check are present
in this tree (blame shows flattened history under `19eef1d98eeda`). The
purge refactor using `for_each_subchannel_staged(purge_fn, ...)` is
present.

### Step 3.2: Fixes: Tag
**Record:** N/A — no `Fixes:` tag.

### Step 3.3: Related File History
**Record:** Related stable backport exists for the Oct 2025 purge
refactor ("Update purge function to unregister the unused subchannels",
spinics stable list). That refactor introduced the `DEV_STATE_OFFLINE`
check this commit corrects. This appears to be a standalone follow-up
fix, not part of a multi-patch series.

### Step 3.4: Author Context
**Record:** Vineeth Vijayan has prior s390/cio purge work (e.g.
subchannel unregister during purge, 2021). Peter Oberparleiter
originally introduced purge in 2008 and reviewed this patch.

### Step 3.5: Dependencies
**Record:** Requires the refactored `purge_fn()` using
`for_each_subchannel_staged()` — present in this 6.18.43 tree. Requires
`cdev->online` in `struct ccw_device` — present in
`arch/s390/include/asm/ccwdev.h`. Standalone, no other commits needed.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Patch Discussion
**Record:** `b4 dig -c <commit>` could not be run — commit hash not in
this checkout. Lore/spinics search for exact subject returned no match.
Related Oct 2025 purge refactor discussion found on spinics stable list.

### Step 4.2: Reviewers
**Record:** Reviewed-by Peter Oberparleiter (subsystem maintainer). Full
recipient list unverified (no commit hash for `b4 dig -w`).

### Step 4.3: Bug Report
**Record:** N/A — no Reported-by or Link tags.

### Step 4.4: Related Patches
**Record:** Follow-up to the Oct 2025 purge refactor that was backported
to stable 6.17. Same functional area, same author/maintainer.

### Step 4.5: Stable List History
**Record:** Prior purge fix in this area was nominated/backported to
stable (6.17 series). No stable-list discussion found for this specific
commit.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** `purge_fn()`, `ccw_purge_blacklisted()`,
`blacklist_parse_proc_parameters()` (purge trigger).

### Step 5.2: Callers
**Record:**
- `ccw_purge_blacklisted()` ← `blacklist_parse_proc_parameters()` on
  `"purge"` via `/proc/cio_ignore`
- Triggered by root/admin: `echo purge > /proc/cio_ignore`

### Step 5.3: Callees
**Record:** `sch_get_cdev()`, `atomic_cmpxchg(&onoff)`,
`ccw_device_sched_todo(CDEV_TODO_UNREG)`,
`css_sched_sch_todo(SCH_TODO_UNREG)`.

### Step 5.4: Reachability
**Record:** Reachable from procfs by privileged users during device
management. Documented admin workflow on IBM Z/s390.

### Step 5.5: Similar Patterns
**Record:** `sch_get_action()` at line 1443 uses `if (cdev->online)` for
the same semantic distinction. `ccw_device_notify()` checks
`!cdev->online` before notifying drivers.

---

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

### Step 6.1: Buggy Code Present?
**Record:** **Yes.** At line 1332:

```1331:1333:drivers/s390/cio/device.c
        if (cdev) {
                if (cdev->private->state != DEV_STATE_OFFLINE)
                        goto unlock;
```

`purge_fn()` with `for_each_subchannel_staged()` is present. Bug is
reachable in this tree.

### Step 6.2: Backport Complications
**Record:** **Clean apply.** Verified with `git apply --check` — hunk
applies with 1-line offset only.

### Step 6.3: Related Fixes Already Present?
**Record:** Oct 2025 purge refactor is present; this specific online-
status fix is **not** yet applied.

---

## Phase 7: Subsystem Context

### Step 7.1: Subsystem and Criticality
**Record:** `drivers/s390/cio/` — s390 Channel I/O layer. **IMPORTANT**
for s390/IBM Z platforms; **PERIPHERAL** globally.

### Step 7.2: Subsystem Activity
**Record:** Active — recent stable backports in this tree include
`6715560527e34` (lifecycle fix) and `600ad63124dea` (CHSC GFP_DMA).

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** s390/IBM Z administrators using `cio_ignore` purge to remove
blacklisted offline devices. Config/platform-specific, not universal.

### Step 8.2: Trigger Conditions
**Record:** Running `echo purge > /proc/cio_ignore` while blacklisted
devices are offline (`online == 0`) but FSM state is not yet
`DEV_STATE_OFFLINE` (during offline transition, or in states like
BOXED/NOT_OPER). Requires root. Moderately common in dynamic device
management workflows.

### Step 8.3: Failure Mode Severity
**Record:** **MEDIUM** — documented admin operation silently fails to
deregister some devices. No crash, corruption, deadlock, or security
issue. Leaves stale device/subchannel registrations; workaround is to
re-run purge after FSM settles.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** Restores documented purge semantics ("not online" devices
  removed); aligns with maintainer intent and prior stable precedent for
  purge fixes.
- **Risk:** Very low — one-line logic change, maintainer-reviewed,
  protected by `onoff` atomic.
- **Ratio:** Moderate benefit for s390 admins, very low risk.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Real functional bug in documented admin interface
- Maintainer-reviewed (Peter Oberparleiter)
- Minimal, obviously correct, applies cleanly to 6.18.43
- Buggy code confirmed present in this tree
- Aligns with `cdev->online` semantics used elsewhere in same file
- Prior purge fix in same area was backported to stable

**AGAINST backport:**
- No crash, security, corruption, or deadlock
- No user/fuzzer reports
- s390-specific, narrow audience
- Workaround exists (retry purge after offline completes)
- Does not meet strictest interpretation of "important issue"

**Unresolved:** Original lore thread and mainline commit hash not found;
no explicit stable nomination found.

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — logic verified against
   `ccw_device_set_offline()` and `sch_get_action()`; maintainer
   reviewed; no runtime test tag.
2. Fixes a real bug affecting users? **PASS** — breaks documented
   `cio_ignore` purge behavior on s390.
3. Important issue? **BORDERLINE PASS** — functional/admin correctness,
   not crash-level; prior purge fixes in this area were deemed stable-
   worthy.
4. Small and contained? **PASS** — 1-line logic change.
5. No new features or APIs? **PASS**.
6. Can apply to local tree? **PASS** — verified clean apply.

### Step 9.3: Exception Categories
**Record:** None (not device ID, quirk, DT, build, or docs fix).

### Step 9.4: Decision Rationale
This is a small, maintainer-reviewed correctness fix for a long-standing
s390 admin feature (`cio_ignore` purge). The bug is present in 6.18.43,
the fix applies cleanly, and it restores behavior explicitly documented
since 2008: remove blacklisted devices that are "not online." While not
crash-level, the s390 maintainers have previously backported purge fixes
to stable, and this is a direct follow-up correcting the same feature.
The low risk and clear correctness outweigh the moderate (non-critical)
severity.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body; no Reported-by/syzbot;
  Reviewed-by Peter Oberparleiter confirmed.
- **[Phase 2]** Diff: 1-line change in `purge_fn()` from FSM state check
  to `cdev->online` check.
- **[Phase 3]** `git describe HEAD`: v6.18.43; buggy code at line 1332
  confirmed; `for_each_subchannel_staged(purge_fn)` present.
- **[Phase 3]** `git blame -L 1319,1350`: purge_fn with
  DEV_STATE_OFFLINE check present.
- **[Phase 4]** `b4 dig -c`: failed — no commit hash in tree. Spinics
  search: related Oct 2025 purge backport found; exact patch thread not
  found.
- **[Phase 4]** Spinics stable msg884366: prior purge refactor backport
  documented.
- **[Phase 5]** `grep ccw_purge_blacklisted`: called from `blacklist.c`
  on `"purge"` proc command.
- **[Phase 5]** Read `ccw_device_set_offline()`: `cdev->online = 0` at
  line 289 before FSM final state.
- **[Phase 5]** Read `sch_get_action()`: uses `cdev->online` at line
  1443 for same semantic.
- **[Phase 6]** `git describe HEAD`: 6.18.43 tree; buggy code present.
- **[Phase 6]** `git apply --check`: patch applies cleanly.
- **[Phase 6]** `struct ccw_device.online` confirmed in
  `arch/s390/include/asm/ccwdev.h` line 96.
- **[Phase 8]** Failure mode: silent purge failure, severity MEDIUM (not
  CRITICAL).
- **UNVERIFIED:** Mainline commit hash; full lore review thread;
  explicit stable nomination for this specific commit.

**YES**

 drivers/s390/cio/device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/s390/cio/device.c b/drivers/s390/cio/device.c
index 4b2dae6eb3760..7f8f78b1f8aea 100644
--- a/drivers/s390/cio/device.c
+++ b/drivers/s390/cio/device.c
@@ -1329,7 +1329,7 @@ static int purge_fn(struct subchannel *sch, void *data)
 
 	cdev = sch_get_cdev(sch);
 	if (cdev) {
-		if (cdev->private->state != DEV_STATE_OFFLINE)
+		if (cdev->online)
 			goto unlock;
 
 		if (atomic_cmpxchg(&cdev->private->onoff, 0, 1) != 0)
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.15] s390/cio: Purge based on the cdev's online status

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Purging devices in intermediate FSM recognition states leads to a use-after-free when un-canceled FSM timers expire.
- [High] The `cdev->online` check in `purge_fn()` introduces a race condition with active device offlining, leading to a NULL pointer dereference.
--

commit 78ddd0e46a2cf7d853e46c6adaa8bbe4677d971f
Author: Vineeth Vijayan <vneethv@linux.ibm.com>

s390/cio: Purge based on the cdev's online status

This commit updates the purging logic to rely on the online variable in
the cdev structure rather than the internal FSM state, ensuring offline
devices are purged correctly.

> diff --git a/drivers/s390/cio/device.c b/drivers/s390/cio/device.c
> index 4b2dae6eb3760..7f8f78b1f8aea 100644
> --- a/drivers/s390/cio/device.c
> +++ b/drivers/s390/cio/device.c
> @@ -1329,7 +1329,7 @@ static int purge_fn(struct subchannel *sch, void *data)
>  
>  	cdev = sch_get_cdev(sch);
>  	if (cdev) {
> -		if (cdev->private->state != DEV_STATE_OFFLINE)
> +		if (cdev->online)

[Severity: High]
Can this change introduce a use-after-free for devices in intermediate
recognition states?

If a device is in an intermediate state like DEV_STATE_SENSE_ID (where
cdev->online == 0), is blacklisted, and a purge is triggered via
/proc/cio_ignore, this new check allows the purge to proceed. Since sysfs
is not holding the onoff atomic, purge schedules CDEV_TODO_UNREG.

This leads to the device memory being freed because it hasn't been added
yet, bypassing device_del():

drivers/s390/cio/device.c:ccw_device_release() {
	...
	kfree(cdev->private);
	kfree(cdev);
}

However, the pending FSM timer is never canceled before freeing. When it
later expires, can it dereference the freed memory?

drivers/s390/cio/device_fsm.c:ccw_device_timeout() {
	struct ccw_device_private *priv = timer_container_of(priv, t, timer);
	struct ccw_device *cdev = priv->cdev;

	spin_lock_irq(cdev->ccwlock);
	...
}

[Severity: High]
Could this also introduce a race condition with active device offlining,
leading to a NULL pointer dereference?

When a driver initiates ccw_device_set_offline(), it clears cdev->online
early, drops locks, and waits for the FSM to transition to an offline state.

If a purge is concurrently triggered during this window, purge_fn() now sees
cdev->online == 0, grabs the onoff atomic, and schedules unregistration. The
workqueue then unlinks the device:

drivers/s390/cio/device.c:ccw_device_todo() {
	...
	sch_set_cdev(sch, NULL);
}

When the offlining thread wakes up and calls io_subchannel_quiesce(), it
fetches the now-NULL cdev and attempts to dereference its handler:

drivers/s390/cio/device.c:io_subchannel_quiesce() {
	cdev = sch_get_cdev(sch);
	...
	if (cdev->handler)
		cdev->handler(cdev, cdev->private->intparm, ERR_PTR(-EIO));
}

Can this result in a kernel panic if the purge occurs during the offlining
race window?

>  			goto unlock;
>  
>  		if (atomic_cmpxchg(&cdev->private->onoff, 0, 1) != 0)
>  			goto unlock;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-536-sashal@kernel.org?part=1