[PATCH AUTOSEL 6.18-5.10] scsi: qla2xxx: Handle INTx not connected while passing through

[PATCH AUTOSEL 6.18-5.10] scsi: qla2xxx: Handle INTx not connected while passing through

[Sasha Levin]

From: Shivaprasad G Bhat <sbhat@linux.ibm.com>

[ Upstream commit 7268e509b43ac1734e1bdb7d18553f7e1080dfb4 ]

The PCI_INTERRUPT_PIN reports if the device supports the INTx.  However,
when the device is assigned to a guest via vfio, the PCI_INTERRUPT_PIN
is set to 0 (i.e none) if the line is not connected and/or the platform
cannot route the interrupt.

In such cases, the guest PCI_INTERRUPT_PIN is 0 and the port number
becomes -1 (255, uint8_t underflow) for qla[25|27|28]xx and qla2031
devices.  The flt_region_nvram is never set, and subsequently the LUN
detection fails.  Below warnings show the NVRAM configuration failure:

 []-0073:1: Inconsistent NVRAM checksum=0xffffffc0 id=HCAM version=0x100.
 []-0074:1: Falling back to functioning (yet invalid -- WWPN) defaults.
 []-0076:1: NVRAM configuration failed.

Handle this case and set the port_no to devfn like its done everywhere
else.

Reference: commit 2bd42b03ab6b ("vfio/pci: Virtualize zero INTx PIN if no pdev->irq")
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Reviewed-by: Kyle Mahlkuch <kmahlkuc@linux.ibm.com>
Link: https://patch.msgid.link/177885270578.1573.14283751510936407585.stgit@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.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: `[scsi/qla2xxx] [Handle] Handle INTx not connected while passing
through`
Subsystem is the QLogic Fibre Channel driver. The verb “Handle” is a
correctness/workaround fix, not a feature add.

**Step 1.2: Tags**
Record:
- `Reviewed-by: Kyle Mahlkuch <kmahlkuc@linux.ibm.com>`
- `Link: https://patch.msgid.link/177885270578.1573.14283751510936407585
  .stgit@linux.ibm.com`
- `Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>` (author)
- `Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>` (SCSI
  maintainer)
- `Reference: commit 2bd42b03ab6b ("vfio/pci: Virtualize zero INTx PIN
  if no pdev->irq")` (not a `Fixes:` tag)
- No `Fixes:`, no `Cc: stable`, no `Reported-by`/`Tested-by` on the
  committed version (those were requested on-list but not folded in)
- Ignore pipeline-added Sasha Levin SOB if present (not on this commit)

**Step 1.3: Body**
Record:
- **Bug:** Guest VFIO assignment virtualizes `PCI_INTERRUPT_PIN` to 0
  when INTx is not connected / not routable.
- **Mechanism:** For qla25/27/28xx and qla2031, the driver does
  `ha->port_no--` on that register. `port_no` is `uint8_t`, so 0 wraps
  to 255.
- **Symptom:** `flt_region_nvram` is never selected (only ports 0–3 are
  matched). NVRAM is read from the wrong/zero flash offset. Logs:
  - `Inconsistent NVRAM checksum=0xffffffc0 id=HCAM version=0x100`
  - `Falling back to functioning (yet invalid -- WWPN) defaults`
  - `NVRAM configuration failed`
- **User-visible result:** LUN detection fails; the HBA does not present
  storage in the guest.
- **Fix:** If PIN is 0, set `port_no` from `PCI_FUNC(devfn)`, matching
  other qla2xxx paths.

**Step 1.4: Hidden bug fix?**
Record: No. This is an explicit functional bug fix, not cleanup
disguised as a fix.

---

## Phase 2: Diff analysis

**Step 2.1: Inventory**
Record:
- File: `drivers/scsi/qla2xxx/qla_os.c` (+10 / −5)
- Function: `qla2x00_set_isp_flags()`
- Scope: single-file surgical change

**Step 2.2: Code flow**
Before (verified on `7268e509b43ac^`):
```c
pci_read_config_byte(ha->pdev, PCI_INTERRUPT_PIN, &ha->port_no);
if (IS_QLA25XX(ha) || IS_QLA2031(ha) || IS_QLA27XX(ha) ||
IS_QLA28XX(ha))
    ha->port_no--;
else
    ha->port_no = !(ha->port_no & 1);
```
After: if PIN is 0, `ha->port_no = PCI_FUNC(ha->pdev->devfn)`; else keep
the old mapping.

This is probe/init (`qla2x00_probe_one` → `qla2x00_set_isp_flags`), not
an error path.

**Step 2.3: Bug category**
Record: **Logic / correctness + hardware/virt workaround**, with a
**uint8_t underflow**.

Verified:
- `qla_def.h`: `uint8_t port_no` — decrement of 0 → 255.
- `qla_sup.c` `qla2xxx_get_flt_info()` only assigns `flt_region_nvram`
  when `port_no` is 0, 1, 2, or 3. 255 never matches.
- `ha` is `kzalloc`’d, so `flt_region_nvram` stays 0; NVRAM is then read
  from flash offset 0.
- `qla81xx`/`27xx` NVRAM path at `qla_init.c:10044–10288` emits exactly
  log IDs 0x0073 / 0x0074 / 0x0076 from the commit message.
- Fallback WWPNs are invalid → LUN discovery fails.

**Step 2.4: Fix quality**
Record: Obviously correct. PIN 0 means “no INTx”; using PCI function
number is already how this driver sets `ha->portnum` for 83xx/82xx/etc.
Bare-metal cards with PIN 1–4 are unchanged. Regression risk is low: the
new branch only runs when PIN is 0, which previously produced a useless
port number (255) on the 25/27/28/2031 path.

---

## Phase 3: Git history

**Step 3.1: Blame**
Record:
- `pci_read_config_byte(..., PCI_INTERRUPT_PIN, &ha->port_no)`
  introduced in `a9083016a5314b` (2010, ISP82XX support).
- Decrement / `!(pin & 1)` mapping in `f73cb695d3eccd` (2014, ISP2071).
- The underflow is old; it became commonly hit after VFIO started
  virtualizing PIN as 0.

**Step 3.2: Fixes tag**
Record: No `Fixes:` tag. Related cause: `2bd42b03ab6b` (`vfio/pci:
Virtualize zero INTx PIN if no pdev->irq`, 2025-04-14). That commit
**is** an ancestor of this tree (`git merge-base --is-ancestor` exit 0).
It was reported/tested by the same author (Shivaprasad G Bhat).

**Step 3.3: File history**
Record: Standalone one-patch series. Later `3571ef0515640` (QLA29xx
support) merged this PIN==0 check with an extra `IS_QLA29XX` in the
decrement branch. No prerequisite refactor is required for the original
hunk.

**Step 3.4: Author**
Record: Shivaprasad G Bhat (IBM). Other nearby work is
powerpc/vfio/iommu, not qla2xxx maintainer. Reviewer Kyle Mahlkuch is
also IBM. SCSI maintainer Martin K. Petersen applied it.

**Step 3.5: Dependencies**
Record: Self-contained. No new APIs. Does not require vfio source
changes; it only reacts to PIN=0 in config space. Can apply standalone
to any tree that still has the old decrement logic.

---

## Phase 4: Mailing list / external

**Step 4.1: Original discussion**
Record:
- `b4 dig -c 7268e509b43ac` → https://patch.msgid.link/177885270578.1573
  .14283751510936407585.stgit@linux.ibm.com
- `b4 dig -a`: **v1 only** (single standalone patch).
- Thread saved to mbox (lore HTTP 403 via WebFetch; mbox succeeded).
- Reviewer feedback:
  - Priya A: tested, asked for `Reported-by`/`Tested-by` (not added in
    the committed version).
  - Kyle Mahlkuch: “look reasonable and fix a known bug” + `Reviewed-
    by`.
  - Madhavan Srinivasan: ping for comments; no NAK.
  - Martin K. Petersen: applied to **7.3/scsi-queue**.
  - Author then asked to also land in **7.2**. Martin: left it in 7.3
    because of conflict with a large qla2xxx update that cycle, and told
    the author they **can post a stable backport request** once Linus
    merged SCSI.

No NAKs. Maintainer explicitly treated this as stable-worthy.

**Step 4.2: Recipients (`b4 dig -w`)**
Record: Marvell qla2xxx maintainers (`njavali@marvell.com`, `GR-QLogic-
Storage-Upstream@marvell.com`), James Bottomley, Martin K. Petersen,
`linux-scsi`, Alex Williamson (vfio), Kyle Mahlkuch.

**Step 4.3: Bug report**
Record: Concrete guest logs in the commit. Independent tester Priya A
confirmed it fixes LUN detection. This is a real IBM-reported VFIO
passthrough failure, not theoretical.

**Step 4.4: Series**
Record: Standalone `[PATCH]`, not `N/M`.

**Step 4.5: Stable list**
Record: lore.kernel.org/stable search returned HTTP 403. From the scsi
thread, the maintainer invited a stable request; no evidence of a NAK
against stable.

---

## Phase 5: Semantic analysis

**Step 5.1: Functions**
Record: `qla2x00_set_isp_flags()` only.

**Step 5.2: Callers**
Record: Called once from `qla2x00_probe_one()` (`qla_os.c:3090`), the
PCI `.probe` callback (`qla_os.c:8360`). Probe context, once per
adapter.

**Step 5.3: Callees**
Record: `pci_read_config_byte()`, `PCI_FUNC()`, ISP type macros. No
alloc/lock changes.

**Step 5.4: Reachability**
Record: Yes. Trigger: VFIO-assign a QLogic 25/27/28xx or 2031 HBA into a
guest whose kernel runs this driver, when the platform does not connect
INTx (`pdev->irq == 0` or `IRQ_NOTCONNECTED`). Confirmed in
`vfio_pci_config.c:1833–1835`. Userspace (hypervisor admin) can trigger
this; unprivileged guest users then just see missing LUNs.

**Step 5.5: Similar patterns**
Record: `PCI_FUNC(ha->pdev->devfn)` is already used for `ha->portnum` in
`qla_os.c` (83xx and others) and `qla_nx.c`. The fallback matches
existing driver convention.

---

## Phase 6: Local tree (this checkout)

**Step 6.1: Does the buggy code exist here?**
Record:
- Tree: **Linux 7.3.0-rc4** (`git describe HEAD` =
  `v7.3-rc4-27-gf0100363d8c37`).
- `qla2xxx` is present. `port_no` is still `uint8_t`. FLT NVRAM
  selection still keys off `port_no` 0–3.
- VFIO PIN=0 virtualization is present (`2bd42b03ab6b` is an ancestor).
- The underflow logic **did exist** on this 7.3 line before
  `7268e509b43ac`; that commit is already an ancestor of HEAD. Current
  `qla2x00_set_isp_flags()` already has the PIN==0 fallback, plus a
  later `IS_QLA29XX` merge.

**Step 6.2: Backport difficulty**
Record: On this 7.3-rc4 tree the fix is already merged. Cherry-picking
again would be a no-op / conflict with the already-applied hunk plus
QLA29xx. For *this* tree, the code change is already in place; no extra
backport rework is needed for 7.3.

**Step 6.3: Related fixes already here?**
Record: This is the fix. The only later related edit is QLA29xx
extending the same `else if` (still keeps the PIN==0 path). No
alternate/competing fix.

---

## Phase 7: Subsystem context

**Step 7.1:**
Record: `drivers/scsi/qla2xxx` — **IMPORTANT** (widely used FC HBA in
servers/SAN, including VFIO passthrough). Not core mm/vfs, but storage
init failure is user-visible and serious for those systems.

**Step 7.2:**
Record: Actively developed (QLA29xx series and hardening landed after
this commit in 7.3). The buggy PIN mapping itself dates to 2010/2014.

---

## Phase 8: Impact and risk

**Step 8.1: Who is affected**
Record: Driver-specific + config-specific: `CONFIG_SCSI_QLA_FC` guests
(and hosts) where `PCI_INTERRUPT_PIN` reads as 0. Primary real-world
trigger is VFIO passthrough when INTx is not routed (IBM Power and
similar). Dual-port 25/27/28xx and 2031 adapters.

**Step 8.2: Trigger**
Record: Adapter probe in the guest. Deterministic once PIN is 0 — not a
race. Hypervisor admin can trigger it; then LUNs never appear.

**Step 8.3: Failure mode**
Record: HBA comes up with invalid NVRAM/WWPN; **LUN detection fails**.
Not a panic/UAF. Severity: **HIGH** (device non-functional, storage
unavailable). Matches stable-rules “hardware quirk” / “oh, that's not
good”.

**Step 8.4: Risk-benefit**
Record:
- Benefit: high for VFIO+qla2xxx users (adapter actually works).
- Risk: very low (10 lines, PIN==0 only, existing `PCI_FUNC`
  convention).
- Ratio: strongly favors including the fix in this tree.

---

## Phase 9: Synthesis

**Evidence FOR:**
- Real, tested LUN-detection failure with matching driver logs.
- uint8_t underflow is verified in this tree’s types and FLT matching.
- Tiny, obviously correct, no new API.
- Reviewed, maintainer-applied to 7.3; maintainer invited a stable
  backport.
- This 7.3 tree has both qla2xxx and the VFIO PIN=0 behavior.

**Evidence AGAINST:**
- Not a crash, UAF, or CVE.
- Affects VFIO passthrough more than bare metal (PIN is usually 1–4 on
  real silicon).
- Committed message omitted the tester’s `Reported-by`/`Tested-by`
  (quality of tags, not of the fix).

**Unresolved:** HTTP 403 on lore WebFetch (mbox was used instead).
Stable-list search unverified beyond the scsi thread.

**Stable rules checklist:**
1. Obviously correct and tested? **PASS** (review + Priya A test +
   maintainer apply)
2. Real bug affecting users? **PASS** (LUN detection fails)
3. Important? **PASS** (HBA/storage unusable in VFIO guests — HIGH)
4. Small and contained? **PASS** (~15 lines, one function)
5. No new features/APIs? **PASS**
6. Applies to this local tree? **PASS** (7.3 already contains the
   change; the surrounding driver is present)

**Exception category:** Hardware/virt workaround (handle virtualized
INTx PIN=0), analogous to a device quirk.

This tree is **7.3-rc4**. The qla2xxx PIN-to-`port_no` bug and VFIO PIN
virtualization both exist on this line. The patch is a small, tested
correctness fix that restores NVRAM/LUN discovery for passed-through
QLogic adapters. It meets stable-kernel rules and belongs in this tree.

Verification:
- [Phase 1] Parsed subject/tags/body from `git log -1` on
  `7268e509b43ac`; no Fixes/Cc-stable; Reference 2bd42b03ab6b.
- [Phase 2] Diff is 15 lines in `qla2x00_set_isp_flags`; parent blob
  still has unconditional `--`.
- [Phase 2] `port_no` is `uint8_t` in `qla_def.h:4319`; FLT NVRAM only
  matches ports 0–3 in `qla_sup.c`.
- [Phase 2] Log IDs 0x0073/0x0074/0x0076 verified in `qla_init.c`.
- [Phase 3] Blame: PIN read `a9083016a5314b` (2010); decrement
  `f73cb695d3eccd` (2014).
- [Phase 3] `git merge-base --is-ancestor 2bd42b03ab6b HEAD` = yes; same
  for `7268e509b43ac`.
- [Phase 3] Author log: IBM powerpc/vfio contributor; one qla2xxx
  commit.
- [Phase 4] `b4 dig -c/-a/-w/-m`: v1 only; scsi CCs including vfio and
  Marvell; mbox has Priya test, Kyle R-b, Martin apply + stable-backport
  invitation.
- [Phase 4] lore WebFetch 403 — UNVERIFIED via HTTP; used mbox instead.
- [Phase 5] Only caller: `qla2x00_probe_one`; VFIO sets PIN=0 at
  `vfio_pci_config.c:1833–1835`.
- [Phase 6] `git describe HEAD` = `v7.3-rc4-27-gf0100363d8c37`; `make
  kernelversion` = 7.3.0-rc4; current `qla_os.c` already has the PIN==0
  path.
- [Phase 8] Failure: NVRAM fail → invalid WWPN → no LUNs; not a panic.
- UNVERIFIED: whether a stable@vger thread was later posted (lore/stable
  HTTP 403).

**YES**

 drivers/scsi/qla2xxx/qla_os.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 07ccfe0226c5e..5b1fb7e5e0980 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -2803,11 +2803,16 @@ qla2x00_set_isp_flags(struct qla_hw_data *ha)
 	else {
 		/* Get adapter physical port no from interrupt pin register. */
 		pci_read_config_byte(ha->pdev, PCI_INTERRUPT_PIN, &ha->port_no);
-		if (IS_QLA25XX(ha) || IS_QLA2031(ha) ||
-		    IS_QLA27XX(ha) || IS_QLA28XX(ha))
-			ha->port_no--;
-		else
-			ha->port_no = !(ha->port_no & 1);
+		if (ha->port_no == 0) {
+			/* None of INT[A|B|C|D] may be virtualized by vfio */
+			ha->port_no = PCI_FUNC(ha->pdev->devfn);
+		} else {
+			if (IS_QLA25XX(ha) || IS_QLA2031(ha) ||
+			    IS_QLA27XX(ha) || IS_QLA28XX(ha))
+				ha->port_no--;
+			else
+				ha->port_no = !(ha->port_no & 1);
+		}
 	}
 
 	ql_dbg_pci(ql_dbg_init, ha->pdev, 0x000b,
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] scsi: snic: Fix SCSI host leak on workqueue allocation failure

[Sasha Levin]

From: Chen Changcheng <chenchangcheng@kylinos.cn>

[ Upstream commit 12e67eb89eb2b9516685c744d3f7de0a2d1bd701 ]

In snic_add_host(), if scsi_add_host() succeeds but
alloc_ordered_workqueue() fails, the function returns -ENOMEM with
shost->work_q left as NULL. The caller's error path then calls
snic_del_host(), which returns early when !shost->work_q without calling
scsi_remove_host(). The Scsi_Host remains registered in sysfs as a zombie
device even after the probe has failed. This causes:

 - The leaked host remains visible in /sys/class/scsi_host/ after probe
   failure, with state "running".

 - Subsequent SCSI host numbering is permanently shifted (the leaked host
   ID from ida_alloc() is never reclaimed).

 - Memory leak: the Scsi_Host allocation can never be freed because
   device_add() took a reference that can only be released by device_del()
   inside scsi_remove_host().

Fix by adding scsi_remove_host() in the workqueue allocation failure path
inside snic_add_host(), undoing the successful scsi_add_host() before
returning the error. This is cleaner than modifying snic_del_host() because
snic_del_host() is called from a shared error label that also serves paths
where snic_add_host() was never invoked.

Reproducer (requires no real SNIC hardware):

 - Build CONFIG_SCSI_SNIC=y (built-in)

 - Add snic.test_mode=1 snic.inject_wq_fail=1 to kernel cmdline

 - Boot with a PCI device matching the snic driver (e.g. QEMU edu device,
   PCI ID 0x1234:0x11e8, temporarily added to the driver's PCI ID table)

Before the fix:

  # /sys/class/scsi_host/ contains a zombie host0:
  $ cat /sys/class/scsi_host/host0/proc_name
  snic_scsi
  $ cat /sys/class/scsi_host/host0/state
  running
  # ata_piix gets host1, host2 (host0 stuck):
  scsi host1: ata_piix
  scsi host2: ata_piix

After the fix:

  # host0 is properly freed and reused by ata_piix:
  scsi host0: ata_piix
  scsi host1: ata_piix
  # No zombie host in /sys/class/scsi_host/

Signed-off-by: Chen Changcheng <chenchangcheng@kylinos.cn>
Acked-by: Narsimhulu Musini <nmusini@cisco.com>
Link: https://patch.msgid.link/20260727073438.209673-1-chenchangcheng@kylinos.cn
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The local tree is **6.12.111** (`pending-6.12`). The buggy
`snic_add_host()` / `snic_del_host()` error path is present here and the
one-line fix applies cleanly.

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

**Step 1.1: PARSE THE SUBJECT LINE**
Record: `[scsi: snic:] [Fix] [SCSI host leak when workqueue allocation
fails after scsi_add_host() succeeds]`

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- `Fixes:` **absent** (expected for this review pipeline)
- `Cc: stable@vger.kernel.org` **absent** (expected)
- `Acked-by: Narsimhulu Musini <nmusini@cisco.com>` — original SNIC
  driver author / Cisco maintainer
- `Link: https://patch.msgid.link/20260727073438.209673-1-
  chenchangcheng@kylinos.cn`
- `Signed-off-by: Chen Changcheng <chenchangcheng@kylinos.cn>` (author)
- `Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>` (SCSI
  maintainer)
- `Reported-by:` none
- `Tested-by:` none (author included a concrete reproducer in the body)
- Ignore pipeline `Signed-off-by: Sasha Levin` / `[Upstream commit ...]`
  if present

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record:
- **Bug:** `scsi_add_host()` succeeds, then `alloc_ordered_workqueue()`
  fails. `snic_add_host()` returns `-ENOMEM` with `shost->work_q ==
  NULL`. Probe goes to a shared error label that calls
  `snic_del_host()`, which returns immediately when `!shost->work_q` and
  **never** calls `scsi_remove_host()`.
- **Symptoms:** zombie `/sys/class/scsi_host/hostN` with state
  `running`; SCSI host ID from `ida_alloc()` never reclaimed (later
  hosts are numbered higher); `Scsi_Host` never freed because
  `device_add()`’s reference is only dropped by `device_del()` inside
  `scsi_remove_host()`.
- **Version info:** none in the message. Code dates to the original
  driver (v4.2).
- **Root cause:** error-path rollback does not undo a successful
  `scsi_add_host()` when workqueue alloc fails. Author correctly avoids
  changing `snic_del_host()` because that helper is also used on paths
  that never called `snic_add_host()`.

**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: Not disguised. Explicit leak/rollback fix with a documented
failure mode and a reproducer.

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

**Step 2.1: INVENTORY THE CHANGES**
Record:
- File: `drivers/scsi/snic/snic_main.c` — **+1 line**
- Function: `snic_add_host()`
- Scope: single-file surgical error-path fix

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Record:
- **Before:** on `!shost->work_q`, log, set `ret = -ENOMEM`, return.
  Host stays registered.
- **After:** same path also calls `scsi_remove_host(shost)` before
  returning `-ENOMEM`.
- Path: probe error path only (`snic_probe()` → `snic_add_host()` after
  `scsi_add_host()` succeeded).

Verified call chain in this tree:

```642:649:drivers/scsi/snic/snic_main.c
        ret = snic_add_host(shost, pdev);
        if (ret) {
                ...
                goto err_get_conf;
        }
```

`err_get_conf` later calls `snic_del_host()` (line 690). That helper
still early-returns on `!shost->work_q`, so after this fix it will not
call `scsi_remove_host()` a second time.

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record: **Error-path / resource leak.** Missing undo of
`scsi_add_host()` when workqueue allocation fails. Adding
`scsi_remove_host()` is the matching rollback. Also reclaims the host ID
(`ida_free()` in `scsi_host_dev_release()` after `device_del()`).

**Step 2.4: ASSESS THE FIX QUALITY**
Record:
- Obviously correct: one matching rollback for the successful
  `scsi_add_host()`.
- Not changing `snic_del_host()` avoids calling `scsi_remove_host()` on
  hosts that were never added (`err_get_conf` is also used when
  `snic_get_conf()` fails **before** `snic_add_host()`).
- Regression risk: very low. `scsi_remove_host()` is the documented
  pairing of `scsi_add_host()`. No double-remove: `snic_del_host()`
  still skips when `work_q` is NULL. No lock, API, or data-structure
  change.

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

**Step 3.1: BLAME THE CHANGED LINES**
Record:
- Buggy control flow introduced in `c8806b6c9e824f` (“snic: driver for
  Cisco SCSI HBA”, Narsimhulu Musini, 2015-05-29).
- First appeared: **v4.2-rc1**. Present in this tree (`git merge-base
  --is-ancestor c8806b6c9e824f HEAD` succeeded).
- Nearby `alloc_ordered_workqueue()` rewrite: `6411307b63286e`
  (v6.12-rc1) — formatting only; the leak predates that.

**Step 3.2: FOLLOW THE FIXES: TAG**
Record: No `Fixes:` tag. Introducer is the original driver commit above,
which **is** in this tree.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record: Recent `snic_main.c` history is workqueue-name cleanup
(`6411307b63286`, `b97c0741c7dcc`), slab-name uniqueness, const
template, SPDX. **No prior leak fix.** Standalone one-line patch, not
“X/Y” of a series (msgid `...-1` is a single patch).

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: `git log --author="Chen Changcheng" -- drivers/scsi/` in this
tree is empty (author is not a historical SNIC contributor here). Weight
instead: **Acked-by original driver author** Musini, and SCSI maintainer
Martin K. Petersen applied it.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record: None. Uses existing `scsi_remove_host()`. Reproducer mentions
`snic.test_mode` / `snic.inject_wq_fail`; those parameters **do not
exist in this tree** (local test harness only). The fix itself does not
depend on them.

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

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
Record:
- `b4 dig -c <sha>` cannot be used: the candidate is **not** in this
  checkout (and the first SHA tried was an unrelated merge).
- Submission: msgid `20260727073438.209673-1-chenchangcheng@kylinos.cn`,
  2026-07-27.
- Thread: https://lists.openwall.net/linux-kernel/2026/07/27/428 and
  https://lkml.iu.edu/hypermail/linux/kernel/2607.3/06578.html
- Single revision (no v2/v3). Diff matches the candidate (1 line).
- No NAK. Cisco maintainer Acked-by in-thread. No reviewer asked for
  `Cc: stable`.
- lore.kernel.org fetches returned HTTP 403 from this environment.

**Step 4.2: CHECK WHO REVIEWED THE PATCH**
Record: To/Cc included Cisco SNIC maintainers (`nmusini`, `kartilak`,
`sebaddel`), James Bottomley, Martin K. Petersen, linux-scsi. Ack from
Musini; applied by Petersen.

**Step 4.3: SEARCH FOR THE BUG REPORT**
Record: No syzbot/bugzilla. Author-found with an injected workqueue-fail
reproducer. Before/after sysfs and host-numbering evidence is in the
message.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
Record: Standalone `[PATCH]`, not part of a multi-patch series.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
Record: **UNVERIFIED** — `https://lore.kernel.org/stable/?q=...`
returned 403. No evidence of a prior stable NAK.

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

**Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF**
Record: `snic_add_host()` (modified). Related: `snic_del_host()`,
`snic_probe()`, `scsi_add_host()`, `scsi_remove_host()`.

**Step 5.2: TRACE CALLERS**
Record:
- `snic_add_host()` — only from `snic_probe()` (PCI probe).
- `snic_del_host()` — `snic_probe()` error path (`err_get_conf`) and
  `snic_remove()`.
- Reachable on Cisco SNIC PCI probe, including under memory pressure
  when `alloc_ordered_workqueue()` fails.

**Step 5.3: TRACE CALLEES**
Record: `scsi_add_host()`, `alloc_ordered_workqueue()`,
`scsi_remove_host()` (new). `scsi_remove_host()` sets host state,
unregisters transport, `device_unregister(&shost->shost_dev)`,
`device_del(&shost->shost_gendev)`. Final free and
`ida_free(&host_index_ida, shost->host_no)` happen in
`scsi_host_dev_release()` once refs drop.

**Step 5.4: FOLLOW THE CALL CHAIN**
Record: PCI probe (`snic_probe` → `snic_add_host`). Not a syscall hot
path. Userspace-visible effect when it fires: leftover
`/sys/class/scsi_host/` entry and shifted host numbers for **other**
SCSI drivers (author showed `ata_piix` taking host1/host2 because host0
was stuck).

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: This `if (!shost->work_q) return;` before `scsi_remove_host()`
is unique to snic. Sibling Cisco `fnic` adds the host later and has a
dedicated `err_out_scsi_add_host` label. No duplicate snic copy of this
bug.

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

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**
Record: **Yes.** Local tree: `p-6.12-3-gc504cf0baa3d8`, **6.12.111**,
branch `pending-6.12`.

```305:323:drivers/scsi/snic/snic_main.c
        if (!shost->work_q) {
                SNIC_HOST_ERR(shost, "Failed to Create ScsiHost wq.\n");

                ret = -ENOMEM;
        }

        return ret;
} /* end of snic_add_host */

static void
snic_del_host(struct Scsi_Host *shost)
{
        if (!shost->work_q)
                return;

        destroy_workqueue(shost->work_q);
        shost->work_q = NULL;
        scsi_remove_host(shost);
}
```

Bug present since v4.2.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: **Clean apply.** Surrounding hunk matches the candidate exactly
(`old found: True`, `new already applied: False`).

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
Record: `git log --grep` for this leak / `snic_add_host` / “workqueue
allocation failure” under `drivers/scsi/` found **no** prior fix.

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

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: SCSI driver `drivers/scsi/snic/` (Cisco PCI-Express SCSI HBA,
`CONFIG_SCSI_SNIC`). **PERIPHERAL** hardware, but host-number leak is
**system-wide** for SCSI host IDs.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: Mature/quiet. Driver added 2015; recent churn is mechanical
SCSI-wide workqueue cleanup. Long-standing bug, not a new-code issue.

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

**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: Driver-specific trigger (Cisco SNIC), **plus** any other SCSI
host on the same machine (permanent host ID shift). Config:
`CONFIG_SCSI_SNIC`.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record: Probe-time `alloc_ordered_workqueue()` failure (ENOMEM /
workqueue creation failure). Uncommon, not a hot path, not unprivileged-
syscall. Once it happens, the zombie host and ID leak persist until
reboot.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record:
- Failure: unreclaimable `Scsi_Host`, zombie sysfs device in
  `SHOST_RUNNING`, leaked host ID.
- Severity: **HIGH** for leak class (not a panic). Worse than a one-shot
  `kfree` leak because the object stays in sysfs and shifts numbering
  for later hosts.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record:
- **Benefit:** medium for SNIC users under memory pressure; also
  prevents global SCSI host-id skew.
- **Risk:** very low (1 line, error path only, standard SCSI rollback).
- **Ratio:** favorable.

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

**Step 9.1: COMPILE THE EVIDENCE**

FOR:
- Real error-path leak with concrete sysfs + host-ID consequences,
  reproduced by the author
- Buggy code is in this 6.12 tree (since v4.2)
- One-line, obviously correct pairing of `scsi_remove_host()` with
  successful `scsi_add_host()`
- No double-remove on the shared `err_get_conf` path
- Applies cleanly; no prerequisites
- Acked by original driver author; applied by SCSI maintainer
- Probe-path resource leaks are a common, accepted stable class

AGAINST:
- Trigger is rare (workqueue alloc fail during probe)
- SNIC is a specialized Cisco HBA (small population)
- Not a crash, UAF, or security bug
- Reproducer uses out-of-tree inject knobs (does not affect the patch)

UNRESOLVED:
- Stable-list discussion (lore 403)
- Upstream SHA not in this checkout (`b4 dig` on a local commit was not
  possible)

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — 1-line rollback; author
   showed before/after; maintainer Ack
2. Fixes a real bug that affects users? **PASS** — zombie sysfs host +
   leaked ID + unreclaimable `Scsi_Host`
3. Important issue? **PASS** — unrecoverable resource leak that also
   skews SCSI host numbering for other drivers
4. Small and contained? **PASS** — +1 line, one function
5. No new features or APIs? **PASS**
6. Can apply to the local tree? **PASS** — code matches; clean apply

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: Not a device-ID/quirk/DT/build/docs exception. Ordinary error-
path leak fix.

**Step 9.4: MAKE YOUR DECISION**
This is a real, long-standing probe rollback bug in this 6.12 tree. The
fix is minimal, already reviewed, and undoes `scsi_add_host()` exactly
when that call succeeded and the workqueue did not. Risk of regression
is negligible; leaving it out leaves a zombie SCSI host and a leaked
host ID if SNIC probe hits ENOMEM.

===============================================================
Verification
===============================================================
- [Phase 1] Parsed tags: Acked-by Musini; Link msgid
  `20260727073438.209673-1`; no Fixes/stable Cc (expected)
- [Phase 2] Diff: +1 line in `snic_add_host()` error path;
  `scsi_remove_host(shost)` before `-ENOMEM`
- [Phase 2] Confirmed `snic_probe` uses shared `err_get_conf` which
  calls `snic_del_host()` even when `snic_add_host()` was never invoked
  (lines 630–690)
- [Phase 2] Confirmed `snic_del_host()` early-return on `!work_q` skips
  `scsi_remove_host()` — the leak mechanism
- [Phase 3] `git blame`: buggy code from `c8806b6c9e824f` (v4.2-rc1);
  ancestor of HEAD
- [Phase 3] `git log --oneline -20 -- drivers/scsi/snic/snic_main.c`: no
  prior leak fix
- [Phase 3] `git log --grep` for this leak under `drivers/scsi/`: empty
- [Phase 3] `git log --author="Chen Changcheng" -- drivers/scsi/`: no
  prior commits in this tree
- [Phase 4] `b4 dig -c` on a tree SHA: not applicable (candidate not in
  checkout); used msgid/openwall/lkml instead
- [Phase 4] Openwall/lkml: single-version patch, Acked-by Musini, no NAK
- [Phase 4] lore.kernel.org and lore stable search: HTTP 403 —
  UNVERIFIED
- [Phase 5] Callers: `snic_add_host` only from `snic_probe`;
  `snic_del_host` from probe error + remove
- [Phase 5] `scsi_remove_host()` → `device_del()`;
  `scsi_host_dev_release()` does `ida_free(host_no)`
- [Phase 5] `test_mode`/`inject_wq_fail` not in this tree (reproducer-
  only)
- [Phase 6] `git describe HEAD`: `p-6.12-3-gc504cf0baa3d8`; `make
  kernelversion`: 6.12.111
- [Phase 6] Surrounding code identical to candidate hunk; patch not
  already applied
- [Phase 8] Failure mode: zombie sysfs SCSI host + permanent host-ID
  leak; severity HIGH for leak class, rare trigger
- UNVERIFIED: whether this was already discussed on stable@ (lore 403)

This meets stable-kernel rules for this tree: real leak, small contained
fix, clean apply, no new API.

**YES**

 drivers/scsi/snic/snic_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/snic/snic_main.c b/drivers/scsi/snic/snic_main.c
index 1c24517e4e650..912f9f15dddc3 100644
--- a/drivers/scsi/snic/snic_main.c
+++ b/drivers/scsi/snic/snic_main.c
@@ -305,6 +305,7 @@ snic_add_host(struct Scsi_Host *shost, struct pci_dev *pdev)
 	if (!shost->work_q) {
 		SNIC_HOST_ERR(shost, "Failed to Create ScsiHost wq.\n");
 
+		scsi_remove_host(shost);
 		ret = -ENOMEM;
 	}
 
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] scsi: devinfo: Add BLIST_SKIP_IO_HINTS for EMC Symmetrix

[Sasha Levin]

From: "Ewan D. Milne" <emilne@redhat.com>

[ Upstream commit f06a44e235ef188689ba23ffc72e9e89b10951a9 ]

EMC Symmetrix returns an error on MODE SENSE for page 0Ah subpage 05h
because it does not implement the SBC-5 I/O hints.  These commands began to
be sent as a result of commit 4f53138fffc2 ("scsi: sd: Translate data
lifetime information").  Add BLIST_SKIP_IO_HINTS to avoid sending these
commands because in large configurations the failed commands are displacing
other useful information in internal error logs.

Signed-off-by: Ewan D. Milne <emilne@redhat.com>
Link: https://patch.msgid.link/20260915173800.39117-1-emilne@redhat.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Local tree

This checkout is **6.18.y** (`v6.18.57-155-gcdf239ca885b2`, `VERSION=6`
/ `PATCHLEVEL=18` / `SUBLEVEL=57`). The verdict is only for this tree.

The I/O-hints path and `BLIST_SKIP_IO_HINTS` are already here. At
`v6.18`, the EMC `SYMMETRIX` blacklist entry does **not** skip those
queries, so the bug exists.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject**
- Record: **[scsi/devinfo] [Add] hardware blacklist flag
  `BLIST_SKIP_IO_HINTS` for EMC Symmetrix**

**Step 1.2: Tags**
- Record:
  - `Signed-off-by: Ewan D. Milne <emilne@redhat.com>` (author, Red Hat
    SCSI)
  - `Link:
    https://patch.msgid.link/20260915173800.39117-1-emilne@redhat.com`
  - `Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>` (SCSI
    maintainer)
  - No `Fixes:`, `Reported-by:`, `Tested-by:`, `Cc: stable` (absence is
    expected)
  - Pipeline `Signed-off-by: Sasha Levin` and `[Upstream commit …]`
    ignored

**Step 1.3: Body**
- Record: **Bug:** EMC Symmetrix does not implement SBC-5 I/O hints, so
  `MODE SENSE` page `0Ah` subpage `05h` fails. Those commands started
  after `4f53138fffc2` ("scsi: sd: Translate data lifetime
  information").
- **Symptom:** In large configs, failed commands fill the array’s
  internal error logs and displace useful entries.
- **Root cause:** Kernel probes a mode page the device does not
  implement.
- **Version info:** The probing started with `4f53138fffc2`
  (`v6.9-rc1`); that commit is an ancestor of this tree.

**Step 1.4: Hidden bug fix?**
- Record: **No disguise.** This is an explicit hardware quirk. It is not
  cleanup/refactor.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Record: **1 file**, `drivers/scsi/scsi_devinfo.c`, **+1 / -1**, one
  table entry.
- Function: static `scsi_dev_info_list` initializer (EMC `SYMMETRIX`
  row).
- Scope: **single-file surgical quirk**.

**Step 2.2: Code flow**
- Record: **Before:** flags `BLIST_SPARSELUN | BLIST_LARGELUN |
  BLIST_REPORTLUN2 | BLIST_RETRY_ITF`.
- **After:** same plus `BLIST_SKIP_IO_HINTS`.
- Affected path: `sd_read_io_hints()` during `sd_revalidate_disk()`
  (probe, open/revalidate, rescan). With the flag set it returns
  immediately and does not send `MODE SENSE 0x0A/0x05`.

**Step 2.3: Bug mechanism**
- Record: **[Hardware workaround]** Device-specific skip of an
  unsupported SCSI mode page. Same pattern as USB storage and the Iomega
  ZIP `BLIST_SKIP_IO_HINTS` entries already in this tree.

**Step 2.4: Fix quality**
- Record: **Obviously correct.** One flag bit on an existing
  vendor/product match. Regression risk is **very low**: only EMC
  `SYMMETRIX` skips a feature it does not implement. No API, locking, or
  allocation changes.

---

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
- Record: EMC `SYMMETRIX` row is old (`3441afc672bc` / `29cfc2ab71d96`
  for `BLIST_RETRY_ITF`, 2018). The **new** failure is not that row; it
  is `sd_read_io_hints()` from `4f53138fffc2` (**v6.9-rc1**,
  2024-02-26).

**Step 3.2: Fixes: tag**
- Record: **None.** The message names `4f53138fffc2`. `git merge-base
  --is-ancestor 4f53138fffc2 HEAD` → **yes**. `git describe --contains
  4f53138fffc2` → `v6.9-rc1~12^2~8`.

**Step 3.3: File history**
- Record: Related: `74b25178943fe` ("scsi: devinfo: Add
  BLIST_SKIP_IO_HINTS for Iomega ZIP") — same quirk class, already in
  this 6.18 tree. `633aeefafc9c2` introduced the flag (**v6.10-rc5**),
  also an ancestor. **Standalone**, not patch X/Y.

**Step 3.4: Author**
- Record: Ewan D. Milne is a long-time SCSI contributor (Red Hat).
  Applied by SCSI maintainer Martin K. Petersen. Related flag work by
  Bart Van Assche (`BLIST_SKIP_IO_HINTS` intro, `Cc: stable` there).

**Step 3.5: Prerequisites**
- Record: Needs `BLIST_SKIP_IO_HINTS` and `sd_read_io_hints()` skip
  check. Both exist in `v6.18` (`include/scsi/scsi_devinfo.h:73`,
  `drivers/scsi/sd.c:3235`). **Applies standalone.**

---

## PHASE 4: MAILING LIST / EXTERNAL

**Step 4.1: Original discussion**
- Record: `b4 dig -c f06a44e235ef` →
  https://patch.msgid.link/20260915173800.39117-1-emilne@redhat.com
- **v1 only** (`b4 dig -a`). No NAKs. Laurence Oberman: “Looks good” +
  `Reviewed-by`. Martin Petersen: applied to **7.3/scsi-fixes**
  (`https://git.kernel.org/mkp/scsi/c/f06a44e235ef`). No `Cc: stable` in
  review.

**Step 4.2: Recipients (`b4 dig -w`)**
- Record: Author + `linux-scsi@vger.kernel.org`. SCSI list was CCed;
  maintainer applied it.

**Step 4.3: Bug report**
- Record: No syzbot/bugzilla. Description is operational: array error-
  log overflow in large configs. That is a real enterprise SAN issue,
  not a theoretical one.

**Step 4.4: Series**
- Record: **Standalone 1/1.** ZIP quirk is a sibling pattern, not a
  dependency.

**Step 4.5: Stable list**
- Record: No lore.kernel.org/stable hit for this subject. WebFetch to
  lore returned 403; stable search via WebSearch found nothing relevant.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions**
- Record: No function body change. Table consumed via
  `sdev->sdev_bflags`. Consumer: `sd_read_io_hints()`.

**Step 5.2: Callers**
- Record: `sd_read_io_hints()` is called only from
  `sd_revalidate_disk()` (`drivers/scsi/sd.c:3773`).
- `sd_revalidate_disk()` is called from:
  - `sd_probe()` (disk attach)
  - `sd_open()` if `sd_need_revalidate()`
  - `sd_rescan()`
  - sysfs cache-type store path
- **Process context**, SCSI disk attach/revalidate. In a large Symmetrix
  config this runs once per LUN (often thousands).

**Step 5.3: Callees**
- Record: Without the flag, `scsi_mode_sense(..., modepage=0x0a,
  subpage=0x05, ...)`. On failure (`res < 0`) it already returns; the
  kernel does not oops. Harm is the failed command on the array.

**Step 5.4: Reachability**
- Record: **Yes.** Any EMC Symmetrix LUN probed as `sd` hits this. Not
  an obscure config path.

**Step 5.5: Similar patterns**
- Record: USB storage/`uas` set `BLIST_SKIP_IO_HINTS` because some
  devices **reset** on that page. Iomega ZIP uses it because the query
  makes the drive unusable. Same skip, milder Symmetrix symptom (error-
  log flood).

---

## PHASE 6: LOCAL TREE CROSS-REFERENCE

**Step 6.1: Buggy code in this tree?**
- Record: **Yes.** `v6.18` has `sd_read_io_hints()` and the flag check,
  and the EMC row **without** `BLIST_SKIP_IO_HINTS`. Bug since
  `4f53138fffc2` (v6.9), so it is in 6.18.

**Step 6.2: Backport difficulty**
- Record: **Clean apply.** Parent of the candidate still has the same
  two-line EMC entry as `v6.18`. No refactor of that table.

**Step 6.3: Related fixes already here?**
- Record: Flag infrastructure and ZIP/USB skips are present. **No**
  existing skip for EMC Symmetrix at `v6.18`.

---

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1**
- Record: **[SCSI disk / scsi_devinfo] [IMPORTANT]** — not core mm/VFS,
  but enterprise block storage. EMC/Dell Symmetrix (VMAX/PowerMax
  lineage) is still used on LTS kernels.

**Step 7.2**
- Record: SCSI is actively maintained; this file is a mature quirk
  table, not a new subsystem.

---

## PHASE 8: IMPACT AND RISK

**Step 8.1: Who is affected**
- Record: **Driver/hardware-specific:** hosts with `INQUIRY` vendor
  `EMC` / product `SYMMETRIX`. Typical: datacenter SAN on 6.18 LTS.

**Step 8.2: Trigger**
- Record: **Every disk revalidate** (probe, rescan, some opens). Common
  on boot and device discovery. Unprivileged users do not trigger it
  directly; udev/scan does. Not a race.

**Step 8.3: Failure mode**
- Record: **Not a kernel oops.** Failed `MODE SENSE` is ignored in
  `sd_read_io_hints()`. User-visible issue is **array error-log
  pollution** in large LUN counts, hiding real faults. Severity
  **MEDIUM** for the kernel, **HIGH** operationally on big arrays.
  USB/ZIP cases of the same flag were crash/unusable-device; this is the
  same class of quirk.

**Step 8.4: Risk/benefit**
- Record: **Benefit: high for Symmetrix users, zero for others. Risk:
  very low (1 flag bit, existing match).** Ratio favors backport.

---

## PHASE 9: SYNTHESIS

**Step 9.1: Evidence**

For:
- Real hardware incompatibility with a command 6.18 already sends
- Enterprise arrays, large LUN counts, error-log displacement
- 1-line quirk; `BLIST_SKIP_IO_HINTS` already in this tree
- Same class as USB/ZIP skips; ZIP already on 6.18
- Reviewed and applied to scsi-fixes by the SCSI maintainer
- Applies cleanly to `v6.18`

Against:
- Not a kernel crash, UAF, deadlock, or data corruption
- No `Cc: stable` / `Fixes:`
- Affects only one vendor/product

Unresolved:
- Lore HTTP 403; thread recovered via `b4 dig -m`. No public
  syzbot/bugzilla count of affected arrays.

**Step 9.2: Stable rules**
1. Obviously correct and tested? **PASS** — 1-bit flag; maintainer
   applied; `Reviewed-by: Laurence Oberman`
2. Real bug affecting users? **PASS** — unsupported `MODE SENSE` on
   production arrays
3. Important issue? **PASS** as a hardware quirk (array log overflow in
   large configs). Not a kernel panic.
4. Small and contained? **PASS** — +1/-1, one table row
5. No new features/APIs? **PASS** — uses existing flag
6. Can apply to this tree? **PASS** — flag, consumer, and EMC row all
   present at `v6.18`

**Step 9.3: Exception**
- Record: **Hardware quirk/workaround** (scsi_devinfo blacklist),
  analogous to USB/PCI quirks. That class is accepted for stable.

**Step 9.4: Decision**
This is a one-line device quirk for hardware this 6.18 tree already
probes with I/O-hints `MODE SENSE`. The skip flag and call site exist;
the EMC row does not skip yet. Risk is negligible; benefit is real for
Symmetrix/VMAX deployments. **YES for this tree.**

---

## What this solves for 6.18 users

Since v6.9, `sd_revalidate_disk()` calls `sd_read_io_hints()`, which
issues `MODE SENSE` page 0x0A subpage 0x05. EMC Symmetrix does not
implement that SBC-5 page and returns an error. The kernel already
swallows the error; on arrays with many LUNs those failures fill the
controller’s error logs. Adding `BLIST_SKIP_IO_HINTS` stops the query
for that INQUIRY match only.

It meets stable rules: small, obviously correct, no new API, applies
cleanly, and is a standard scsi_devinfo hardware quirk.

---

## Verification
- **[Phase 1]** Parsed tags: author SOB Ewan Milne, Link to msgid,
  maintainer SOB Martin Petersen; no Fixes/Reported-by/Cc:stable
- **[Phase 2]** Diff: 1 line in `scsi_devinfo.c` EMC SYMMETRIX flags;
  adds `BLIST_SKIP_IO_HINTS`
- **[Phase 3]** `git describe HEAD` / `make kernelversion`: **6.18.57**
- **[Phase 3]** `git merge-base --is-ancestor 4f53138fffc2 HEAD`: yes;
  `git describe --contains`: v6.9-rc1
- **[Phase 3]** `git merge-base --is-ancestor 633aeefafc9c2 HEAD`: yes
  (flag intro, v6.10-rc5)
- **[Phase 3]** `git blame` EMC row: `29cfc2ab71d96` added
  `BLIST_RETRY_ITF` (2018); skip flag is new
- **[Phase 3]** `git show v6.18:drivers/scsi/scsi_devinfo.c`: SYMMETRIX
  **without** `BLIST_SKIP_IO_HINTS`
- **[Phase 3]** `git grep BLIST_SKIP_IO_HINTS v6.18`: flag and `sd.c`
  check present
- **[Phase 4]** `b4 dig -c f06a44e235ef`: lore URL; v1 only; Reviewed-by
  Laurence Oberman; applied to 7.3/scsi-fixes
- **[Phase 4]** `b4 dig -m`: full thread, no NAK, no stable nomination
- **[Phase 4]** WebFetch lore/msgid: **403**; used b4 mbox instead
- **[Phase 5]** Callers: `sd_read_io_hints` ← `sd_revalidate_disk` ←
  `sd_probe` / `sd_open` / `sd_rescan`
- **[Phase 6]** Parent of candidate matches `v6.18` EMC lines → clean
  apply
- **[Phase 8]** Failure: array error-log flood, not kernel oops;
  severity MEDIUM kernel / HIGH operational
- **UNVERIFIED:** Exact customer ticket / number of arrays (not in the
  thread)

**YES**

 drivers/scsi/scsi_devinfo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index c51146882a1fa..a438e510f2cae 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -161,7 +161,7 @@ static struct {
 	{"DGC", "DISK", NULL, BLIST_SPARSELUN},	/* EMC CLARiiON, no storage on LUN 0 */
 	{"EMC",  "Invista", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
 	{"EMC", "SYMMETRIX", NULL, BLIST_SPARSELUN | BLIST_LARGELUN |
-	 BLIST_REPORTLUN2 | BLIST_RETRY_ITF},
+	 BLIST_REPORTLUN2 | BLIST_RETRY_ITF | BLIST_SKIP_IO_HINTS},
 	{"EMULEX", "MD21/S2     ESDI", NULL, BLIST_SINGLELUN},
 	{"easyRAID", "16P", NULL, BLIST_NOREPORTLUN},
 	{"easyRAID", "X6P", NULL, BLIST_NOREPORTLUN},
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] scsi: ibmvfc: free ibmvfc_target allocations with mempool_free

[Sasha Levin]

From: Tyrel Datwyler <tyreld@linux.ibm.com>

[ Upstream commit 99143433f7f14139ac373c553ec8e1317d0ae58a ]

The ibmvfc_target *tgt structures for discovery are allocated using
mempool_alloc but in turn free'd via kfree in ibmvfc_release_target
breaking pool guarentees.

Fixup ibmvfc_release_target to call mempool_free instead so that memory
is properly returned to the mempool instead of the general allocator.

Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-5-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I have enough to decide: this is a one-line mempool/kfree mismatch in
ibmvfc that can drain the target pool and hang discovery. The local
7.3-rc4 tree has the driver and the bug’s code path.

## Phase 1: Commit message forensics

**Step 1.1: Subject**
Record: `[scsi/ibmvfc] [free] free ibmvfc_target allocations with
mempool_free` — claimed intent: stop freeing mempool-allocated target
structs with `kfree`.

**Step 1.2: Tags**
Record:
- `Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>` (author; IBM
  ibmvfc maintainer)
- `Link:
  https://patch.msgid.link/20260723000149.969416-5-tyreld@linux.ibm.com`
- `Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>` (SCSI
  maintainer)
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-
  by:`, or `Cc: stable` (absence of the last two is expected for this
  review)

**Step 1.3: Body**
Record:
- Bug: `ibmvfc_target` objects are allocated with `mempool_alloc()` but
  released with `kfree()` in `ibmvfc_release_tgt` (message says
  `ibmvfc_release_target`; the function is `ibmvfc_release_tgt`).
- Symptom: “breaking pool guarantees” — reserved mempool elements never
  return to the pool.
- Root cause: allocator/free mismatch (`mempool_alloc` vs `kfree`).
- No stack trace, reproducer, or version range. Failure mode is implied
  (pool accounting), not a reported oops.

**Step 1.4: Hidden bug fix?**
Record: Not hidden. It is an explicit allocator-mismatch fix. The cover
letter for the series later names it as one of four pre-existing bugs,
not NVMe feature work.

## Phase 2: Diff analysis

**Step 2.1: Inventory**
Record:
- File at commit time: `drivers/scsi/ibmvscsi/ibmvfc.c` (`1 insertion, 1
  deletion`)
- Function: `ibmvfc_release_tgt`
- Scope: single-file, one-line surgical fix

**Step 2.2: Code flow**
Record:
- Before: last `kref_put` on a target calls `kfree(tgt)`.
- After: same path calls `mempool_free(tgt, tgt->vhost->tgt_pool)`.
- Path: target teardown / kref drain (discovery logout, rport delete,
  sysfs starget accessors, host teardown), not an error-only path.

**Step 2.3: Bug mechanism**
Record: `[resource / mempool accounting]` plus a possible `[hang]`
- Alloc: `tgt = mempool_alloc(vhost->tgt_pool, GFP_NOIO)` in
  `ibmvfc_alloc_target`.
- Pool: `mempool_create_kmalloc_pool(IBMVFC_TGT_MEMPOOL_SZ,
  sizeof(struct ibmvfc_target))` with `IBMVFC_TGT_MEMPOOL_SZ == 64`.
- `kfree` of a reserved pool object returns that slab object to the page
  allocator without incrementing `pool->curr_nr`. After 64 alloc/free
  cycles the reserved pool is empty.
- `mempool_alloc()` with `GFP_NOIO` (`__GFP_RECLAIM` /
  `__GFP_DIRECT_RECLAIM`) first tries `kmalloc`; on failure it waits
  uninterruptibly on `pool->wait` until `mempool_free` refills. If
  nothing ever calls `mempool_free`, that wait never ends.
- Commit `5c66d9393f583` (2017) removed the NULL check on this
  `mempool_alloc` because “mempool_alloc() cannot fail when passed
  GFP_NOIO”. That is only true if the pool is actually returned to.

**Step 2.4: Fix quality**
Record: Obviously correct matching free. Minimal. `tgt->vhost` is set
before `kref_init`, so the pool pointer is valid on the free path.
Regression risk is low. Theoretical extra requirement vs `kfree`: the
pool must still exist; `ibmvfc_remove` does `fc_remove_host` /
`scsi_remove_host` and target `kref_put`s before `ibmvfc_free_mem()` →
`mempool_destroy()`. No later revert of this change.

## Phase 3: Git history

**Step 3.1: Blame**
Record: `kfree(tgt)` in `ibmvfc_release_tgt` comes from `b3c10489cb464b`
/ original driver `072b91f9c6510` (“[SCSI] ibmvfc: IBM Power Virtual
Fibre Channel Adapter Client Driver”, 2008-07-12, contained in
v2.6.27-rc1). The mismatch is as old as the driver. `tgt_pool` was
created in that same commit.

**Step 3.2: Fixes tag**
Record: None. Introducer is the original 2008 driver, present in this
tree’s history.

**Step 3.3: File history**
Record: This commit is `99143433f7f14`. Neighbors from the same
submission:
- `9c2aa65000f6f` 01/33 MAD send-failure deadlock
- `7e35396ec8539` 02/33 rport_add_work_q teardown
- `0122eab60b151` 03/33 NULL evt deref
- **this** 04/33 mempool_free
- `de7ac0f3f08b1` 05/33 move target list (NVMe prep, not required for
  this line)

Standalone relative to 05/33+. Later `848c70852e3fb` split `ibmvfc.c`
into `ibmvfc-core.c`; current tree has the fixed `mempool_free` in
`ibmvfc-core.c`.

**Step 3.4: Author**
Record: Tyrel Datwyler is the IBM ibmvfc maintainer (majority of recent
`drivers/scsi/ibmvscsi/` commits). SCSI maintainer Martin K. Petersen
applied the series.

**Step 3.5: Dependencies**
Record: None for the one-line change. It does not need NVMe/FC patches.
`mempool_free` / `tgt_pool` / `ibmvfc_release_tgt` all exist in this
tree.

## Phase 4: Mailing list

**Step 4.1: b4 dig**
Record:
- Lore:
  https://patch.msgid.link/20260723000149.969416-5-tyreld@linux.ibm.com
- Subject on list: `[PATCH v2 04/33] ibmvfc: free ibmvfc_target
  allocations with mempool_free`
- Series: `[PATCH v2 00/33] ibmvfc: NVMe/FC support over IBM Virtual FC`
  (2026-07-22)
- Cover letter (from saved mbox): “Patches 1-5: Bug fixes and
  preparatory refactoring. Four pre-existing bugs are fixed before any
  NVMe/FC work is introduced: … an allocator mismatch where mempool-
  allocated ibmvfc_target structs are freed via kfree rather than
  mempool_free.”
- Martin K. Petersen: “Applied to 7.3/scsi-staging, thanks!”
- No NAK on this patch. No reviewer asked for `Cc: stable` on this
  specific patch.

**Step 4.2: Recipients (`b4 dig -w`)**
Record: `james.bottomley@hansenpartnership.com`,
`martin.petersen@oracle.com`, `linux-scsi@vger.kernel.org`, `linuxppc-
dev@lists.ozlabs.org`, `brking@linux.ibm.com`, `davemarq@linux.ibm.com`.
Right SCSI/PPC/IBM lists.

**Step 4.3: Bug report**
Record: No `Reported-by` / Bugzilla / syzbot. Bug was found by the
maintainer while preparing NVMe/FC.

**Step 4.4: Series**
Record: 33-patch NVMe/FC feature series. This patch is explicitly a pre-
existing bugfix (phase 1, patches 1–4). Self-contained.

**Step 4.5: Stable list**
Record: UNVERIFIED. lore.kernel.org search hit Anubis bot-protection
(403). No stable discussion in the saved scsi thread mbox.

## Phase 5: Semantic / call graph

**Step 5.1: Functions**
Record: `ibmvfc_release_tgt` only.

**Step 5.2: Callers**
Record: Many `kref_put(&tgt->kref, ibmvfc_release_tgt)` sites in
`ibmvfc-core.c` and `ibmvfc-nvme.c`: starget node/port name/id sysfs,
implicit logout / delete, PLOGI/PRLI, rport add/delete, host work
thread, module remove. Reachable from FC discovery, link events, and
sysfs.

**Step 5.3: Callees**
Record: `container_of`, then `mempool_free`. No new locks or
allocations.

**Step 5.4: Reachability**
Record: Yes, from normal IBM Power virtual FC use (target
discovery/logout and host removal). Not an obscure debug path.
`CONFIG_SCSI_IBMVFC` depends on `PPC_PSERIES`.

**Step 5.5: Similar patterns**
Record: Only this kfree/mempool mismatch for targets. Event pools in the
same driver already used mempool correctly. No follow-up fix after
`99143433f7f14`.

semcode MCP: not available in this session; used `git grep` / file
reads.

## Phase 6: This tree

**Step 6.1: Local tree and buggy code**
Record:
- `git describe HEAD`: `v7.3-rc4-27-gf0100363d8c37`
- `make kernelversion`: `7.3.0-rc4`
- `git merge-base --is-ancestor 99143433f7f14 HEAD`: yes — the fix is
  already in this checkout
- Current code (`ibmvfc-core.c:1431-1434`) already has
  `mempool_free(tgt, tgt->vhost->tgt_pool)`
- The mismatch existed here from v2.6.27 until this commit; the driver
  and `tgt_pool` still exist

**Step 6.2: Backport difficulty**
Record: Clean one-liner against pre-split `ibmvfc.c`. This 7.3-rc4 tree
already contains it; later split to `ibmvfc-core.c` does not change the
correctness of the fix.

**Step 6.3: Related fixes already here**
Record: The fix itself is here. `5c66d9393f583` (NULL-check removal) is
also here, which makes restoring pool refill more important.

## Phase 7: Subsystem

**Step 7.1**
Record: SCSI LLD `drivers/scsi/ibmvscsi/` — IBM Power Virtual FC.
Criticality: IMPORTANT for `PPC_PSERIES` storage (enterprise PowerVM),
PERIPHERAL for everyone else.

**Step 7.2**
Record: Actively developed in 7.3 (large NVMe/FC series). The bug itself
is old, not a new-subsystem issue.

## Phase 8: Impact and risk

**Step 8.1: Who is affected**
Record: Users of `CONFIG_SCSI_IBMVFC` on IBM POWER (pSeries) with
Virtual Fibre Channel. Not universal.

**Step 8.2: Trigger**
Record: Target alloc/free churn (discovery, logout, rport delete, host
reset). After 64 such cycles the reserved pool is empty. Hang requires
subsequent `mempool_alloc(GFP_NOIO)` while `kmalloc` fails (memory
pressure, no `__GFP_FS` reclaim). Unprivileged users do not call this
directly; fabric events and scans do.

**Step 8.3: Failure mode**
Record: Permanent mempool drain; under memory pressure, uninterruptible
hang in `mempool_alloc` during discovery (storage bring-up / recovery
stuck). Severity: HIGH for that platform (hang / lost discovery), not a
KASAN UAF from `kfree` of kmalloc-backed pool memory.

**Step 8.4: Risk-benefit**
Record: Benefit HIGH for ibmvfc users (restore mempool guarantees; avoid
discovery hang). Risk VERY LOW (1 line, matching alloc/free, maintainer-
authored, SCSI maintainer applied). Ratio favors including the fix.

## Phase 9: Synthesis

**Step 9.1: Evidence**

For:
- Real allocator mismatch present since 2008
- One-line, obviously correct `mempool_free`
- Can empty the 64-element pool and then hang `mempool_alloc(GFP_NOIO)`
  under memory pressure
- 2017 change already assumes mempool never fails on this path
- Cover letter labels it a pre-existing bug, independent of NVMe/FC
- IBM/SCSI maintainers; applied to 7.3 scsi-staging
- Driver and bug exist in this 7.3-rc4 tree

Against:
- No user/syzbot report in 18 years (may be rare or attributed to memory
  pressure)
- Sent as 04/33 of a feature series (the line itself does not depend on
  the rest)
- Platform-specific (PowerVM virtual FC only)
- No `Fixes:` / `Cc: stable` (not a negative per the review rules)

Unresolved:
- Stable-list discussion (lore search blocked)

**Step 9.2: Stable rules**
1. Obviously correct and tested? **PASS** — matching free; applied by
   SCSI maintainer.
2. Real bug that affects users? **PASS** — pool contract broken on every
   target free; hang is a realistic stress case.
3. Important (crash/security/corruption/deadlock)? **PASS** —
   uninterruptible wait in discovery if the drained pool cannot be
   refilled; storage recovery hang.
4. Small and contained? **PASS** — 1 line, one function.
5. No new features/APIs? **PASS** — not the NVMe work; just the free
   path.
6. Can apply to this tree? **PASS** — code exists; commit is already an
   ancestor of HEAD; equivalent `mempool_free` is in `ibmvfc-core.c`.

**Step 9.3: Exception category**
Record: None needed (not a device ID/quirk/DT/build/doc exception). It
is a normal bugfix.

**Step 9.4: Decision**
This should be backported to this tree. It is a one-line correction of a
long-standing mempool leak/drain in IBM virtual FC target discovery,
with hang potential under memory pressure, and no meaningful regression
risk.

---

**What it solves for this tree:** `ibmvfc_target` objects come from
`vhost->tgt_pool` but were `kfree`d, so reserved pool slots were
permanently lost. After enough discovery/logout churn,
`mempool_alloc(GFP_NOIO)` no longer has a reserved pool and can block
forever if `kmalloc` fails. This 7.3-rc4 tree still has that driver; the
one-line `mempool_free` restores the guarantee.

**Stable rules:** Small, obviously correct, no new API, real
hang/discovery-failure bug, applies here.

**Risk vs benefit:** Very low risk, high benefit for PowerVM FC users.

**Concerns:** No field crash report; bug is old. That does not make the
mismatch or the hang path hypothetical. No extra commits are required.

Verification:
- [Phase 1] Parsed tags: author Tyrel Datwyler, Link msgid
  `...969416-5`, SOB Martin K. Petersen; no Fixes/Reported-by/Cc:stable
- [Phase 2] Diff: 1 line in `ibmvfc_release_tgt`, `kfree(tgt)` →
  `mempool_free(tgt, tgt->vhost->tgt_pool)`
- [Phase 2] Confirmed alloc at `ibmvfc_alloc_target`:
  `mempool_alloc(vhost->tgt_pool, GFP_NOIO)`; pool size 64; `GFP_NOIO`
  is `__GFP_RECLAIM`
- [Phase 2] `mm/mempool.c`: `mempool_alloc_noprof` retries and waits on
  `pool->wait` when `__GFP_DIRECT_RECLAIM` is set; waiters woken from
  `mempool_free`
- [Phase 3] git blame: `kfree(tgt)` from original driver `072b91f9c6510`
  (2008, v2.6.27-rc1)
- [Phase 3] `git merge-base --is-ancestor 99143433f7f14 HEAD`: yes
- [Phase 3] Related: `5c66d9393f583` (v4.12-rc1) removed mempool_alloc
  NULL check
- [Phase 4] `b4 dig -c 99143433f7f14`: `[PATCH v2 04/33]`; cover letter
  lists this as a pre-existing bug; Martin: applied to 7.3/scsi-staging
- [Phase 4] `b4 dig -w`: linux-scsi, linuxppc-dev, Bottomley, Petersen,
  IBM
- [Phase 4] `b4 dig -a`: v2 of 33-patch NVMe/FC series; this patch is in
  the bugfix prefix
- [Phase 4] UNVERIFIED: lore.kernel.org/stable search (Anubis 403)
- [Phase 5] Callers: many `kref_put(..., ibmvfc_release_tgt)` in
  discovery/teardown/sysfs
- [Phase 6] `git describe HEAD`: v7.3-rc4-27-gf0100363d8c37;
  kernelversion 7.3.0-rc4; current `ibmvfc-core.c` already uses
  `mempool_free`
- [Phase 7] `CONFIG_SCSI_IBMVFC` depends on `PPC_PSERIES`
- [Phase 8] Failure mode: mempool drain → possible D-state hang in
  target discovery under memory pressure; severity HIGH for that
  platform
- UNVERIFIED: whether a target kref can outlive `mempool_destroy` on
  remove (no evidence it does; remove deletes rports first)

**YES**

 drivers/scsi/ibmvscsi/ibmvfc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 63cc569284ded..e3853e05aa27a 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -1366,7 +1366,7 @@ static void ibmvfc_set_rport_dev_loss_tmo(struct fc_rport *rport, u32 timeout)
 static void ibmvfc_release_tgt(struct kref *kref)
 {
 	struct ibmvfc_target *tgt = container_of(kref, struct ibmvfc_target, kref);
-	kfree(tgt);
+	mempool_free(tgt, tgt->vhost->tgt_pool);
 }
 
 /**
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] scsi: ibmvfc: check for NULL evt in implicit LOGO and target delete path

[Sasha Levin]

From: Tyrel Datwyler <tyreld@linux.ibm.com>

[ Upstream commit 0122eab60b151d7815f420a91c7315944a037714 ]

Unlike ibmvfc_tgt_implicit_logout the ibmvfc_tgt_implicit_logout_and_del
path fails to check for a NULL evt returned from
ibmvfc_get_reserved_event and passes that directly to ibmvfc_send_event
which will unconditionally derefence the evt.

Check for a NULL evt and perform same escalation as
ibmvfc_implicit_logout.

Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/20260723000149.969416-4-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This is a real NULL-deref crash fix in ibmvfc’s target-delete path. The
local tree is **v7.3-rc4** (`7.3.0-rc4`); the driver and the buggy call
path exist here, and the change is an 8-line match of the sibling logout
error path.

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

**Step 1.1: PARSE THE SUBJECT LINE**
- Subsystem: `scsi: ibmvfc`
- Action verb: `check` (safety check; commit body describes a NULL
  deref)
- Intent: stop passing a NULL event into `ibmvfc_send_event` on the
  implicit-LOGO + delete path

Record: [scsi/ibmvfc] [check] [NULL evt before send on implicit
logout/delete]

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
- Signed-off-by: Tyrel Datwyler \<tyreld@linux.ibm.com\> (author; IBM
  ibmvfc maintainer/contributor)
- Link:
  https://patch.msgid.link/20260723000149.969416-4-tyreld@linux.ibm.com
- Signed-off-by: Martin K. Petersen \<martin.petersen@oracle.com\> (SCSI
  maintainer)
- No Fixes:, Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, or Cc:
  stable
- Ignore pipeline SOBs if present; none besides author + SCSI maintainer

Record: Author + SCSI maintainer SOB; lore/msgid link; no
Fixes/Reported-by (expected)

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
- Bug: `ibmvfc_tgt_implicit_logout` checks for NULL from event
  allocation; `ibmvfc_tgt_implicit_logout_and_del` does not
- Failure: NULL `evt` is passed to `ibmvfc_send_event`, which
  dereferences it
- Fix: same escalation as the sibling path (drop discovery thread, put
  kref, reset host)

Record: [NULL deref of evt] [kernel oops on target delete when reserved
pool is empty] [no version pins in message] [missed sibling NULL check]

**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: Not hidden. Explicit NULL-deref fix.

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

**Step 2.1: INVENTORY THE CHANGES**
- File at commit: `drivers/scsi/ibmvscsi/ibmvfc.c` (+8 / -0)
- Function: `ibmvfc_tgt_implicit_logout_and_del`
- Scope: single-file surgical error-path

Record: [ibmvfc.c +8] [ibmvfc_tgt_implicit_logout_and_del] [surgical]

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Before: `discovery_threads++` → `__ibmvfc_tgt_get_implicit_logout_evt()`
→ `ibmvfc_send_event(evt)` with no NULL test.
After: if `!evt`, decrement `discovery_threads`,
`ibmvfc_set_tgt_action(NONE)`, `kref_put`, `__ibmvfc_reset_host`,
return.

Record: [error path only: unguarded send → guarded recovery matching
sibling]

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Category: memory safety (NULL pointer dereference), plus leak/refcount
on that path.

Verified mechanism:
- `__ibmvfc_tgt_get_implicit_logout_evt()` does `kref_get` then
  `ibmvfc_get_reserved_event()`; on failure it returns NULL (`ibmvfc-
  core.c` 4424–4427)
- `__ibmvfc_get_event()` can return NULL when the reserved pool is empty
  (1615–1630)
- `ibmvfc_send_event()` starts with `*evt->xfer_iu = evt->iu` (1787) —
  unconditional deref

Record: [NULL deref] [empty reserved event pool → NULL evt → oops; fix
mirrors implicit_logout]

**Step 2.4: ASSESS THE FIX QUALITY**
Obviously correct as a crash fix: must not call
`ibmvfc_send_event(NULL)`, must undo `discovery_threads++`, must
`kref_put` the get done inside the helper.

Caveat (verified in `ibmvfc_set_tgt_action`): this path is entered with
`tgt->action == IBMVFC_TGT_ACTION_LOGOUT_RPORT` (set in
`ibmvfc_del_tgt`). From that state, only `LOGOUT_RPORT_WAIT` or
`DEL_RPORT` are accepted; `ACTION_NONE` is silently ignored. The send-
failure arm already uses `DEL_RPORT`. An automated review (sashiko-bot)
flagged this. It does not reintroduce the NULL deref: `kref_put` still
balances the helper, and `__ibmvfc_reset_host` still runs. Worst case,
the target stays in `LOGOUT_RPORT` and is retried after reset — far
better than an oops.

Record: [minimal, matches sibling; ACTION_NONE is a no-op here but not a
crash regression]

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

**Step 3.1: BLAME THE CHANGED LINES**
- `ibmvfc_tgt_implicit_logout_and_del` introduced in `ed830385a2b1f`
  (“Avoid loss of all paths during SVC node reboot”), contained in
  **v5.7-rc1**
- NULL-returning `get_event` and sibling check added in `b39f2d10b86d0`
  (“Remove BUG_ON in the case of an empty event pool”), contained in
  **v6.7-rc1**. That commit updated
  `__ibmvfc_tgt_get_implicit_logout_evt` and
  `ibmvfc_tgt_implicit_logout` but **left `and_del` unchecked**
  (verified in the post-commit function body)

Record: [and_del: ed830385a2b1f / v5.7] [NULL return + incomplete call-
site update: b39f2d10b86d0 / v6.7]

**Step 3.2: FOLLOW THE FIXES: TAG**
Record: No Fixes: tag. Effective buggy change is b39f2d10b86d0 (in this
tree; `git merge-base --is-ancestor` → YES)

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Series msgid `…969416-4` is **[PATCH v2 03/33]** of “ibmvfc: NVMe/FC
support over IBM Virtual FC”. Cover letter: patches 1–5 are **pre-
existing bug fixes** so the series is bisect-safe. This patch does not
depend on NVMe patches. Neighbors: `9c2aa65000f6f` (MAD send deadlock),
`7e35396ec8539` (teardown flush). Later `848c70852e3fb` split `ibmvfc.c`
→ `ibmvfc-core.c`.

Record: [standalone bugfix in a feature series] [no functional prereq on
later NVMe patches]

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Tyrel Datwyler is the ibmvfc author of the 2023 event-pool change and
this follow-up, plus the NVMe/FC series. Martin K. Petersen applied it.

Record: [subsystem author] [completes his own 2023 call-site sweep]

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Needs `__ibmvfc_tgt_get_implicit_logout_evt` returning NULL,
`ibmvfc_send_event`, `__ibmvfc_reset_host`. All present. Applies as 8
lines with no new APIs.

Record: [standalone vs current driver; prereq b39f2d10b86d0 is in this
tree]

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

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
- `b4 dig -c 0122eab60b151` → [PATCH v2 03/33],
  https://patch.msgid.link/20260723000149.969416-4-tyreld@linux.ibm.com
- `b4 dig -a` → v2 series only in the match: “NVMe/FC support over IBM
  Virtual FC” (2026-07-22)
- Cover letter: this is one of four pre-existing bugs (NULL event deref
  in `and_del`)
- Martin K. Petersen: “Applied to 7.3/scsi-staging, thanks!”
- Direct replies to 03/33: sashiko-bot only (ACTION_NONE concern). No
  human NAK.

Record: [lore msgid above] [v2 03/33] [SCSI maintainer applied] [AI note
on ACTION_NONE, no NAK]

**Step 4.2: CHECK WHO REVIEWED THE PATCH**
`b4 dig -w`: Tyrel Datwyler; James Bottomley; Martin K. Petersen; linux-
scsi; linuxppc-dev; linux-kernel; Brian King; Dave Marquardt.

Record: [SCSI maintainers + IBM ibmvfc people + linuxppc-dev]

**Step 4.3: SEARCH FOR THE BUG REPORT**
No Reported-by / syzbot / bugzilla. Bug described by the driver author
from code comparison with the sibling.

Record: [author-found incomplete 2023 update; no external repro]

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
Standalone among 33; first four are bugfixes. Later patches are NVMe
feature work and must not be required.

Record: [self-contained; do not pull the NVMe series]

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
WebSearch of lore for this subject did not find a stable@ thread. Direct
lore.kernel.org fetches returned 403.

Record: [no stable-list hit found; lore HTTP 403 on direct fetch]

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

**Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF**
Record: [ibmvfc_tgt_implicit_logout_and_del]

**Step 5.2: TRACE CALLERS**
- Declared static; `ibmvfc_del_tgt()` sets `tgt->job_step =
  ibmvfc_tgt_implicit_logout_and_del` when action becomes `LOGOUT_RPORT`
  (687–694)
- Work thread `IBMVFC_HOST_ACTION_TGT_DEL` / `TGT_DEL_FAILED` invokes
  `tgt->job_step(tgt)` for `LOGOUT_RPORT` targets (6085–6097)

Record: [ibmvfc_del_tgt → work queue TGT_DEL → and_del; host work
thread, not IRQ]

**Step 5.3: TRACE CALLEES**
`__ibmvfc_tgt_get_implicit_logout_evt`, `ibmvfc_send_event`,
`ibmvfc_set_tgt_action`, `kref_put`/`ibmvfc_release_tgt`,
`__ibmvfc_reset_host`

Record: [event alloc/send, tgt state, kref, host reset]

**Step 5.4: FOLLOW THE CALL CHAIN**
Trigger: target removal / path loss on IBM Virtual FC (the v5.7 commit
was SVC node reboot / WWPN move). Userspace SCSI/FC path loss on a POWER
guest can reach this. NULL only if reserved CRQ events are exhausted
(`IBMVFC_NUM_INTERNAL_REQ` is small: `1+1+1+2+(disc_threads*2)`).
Unlikely but the 2023 change exists specifically because it can happen;
without this check it is a hard oops rather than recovery.

Record: [reachable on target delete] [NULL when reserved pool empty]
[oops from driver work thread]

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Sibling `ibmvfc_tgt_implicit_logout` already has the same 8-line guard
(4458–4464). This is the missed twin.

Record: [same pattern already in implicit_logout; and_del was the hole]

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

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**
- `git describe HEAD`: **v7.3-rc4-27-gf0100363d8c37**; `make
  kernelversion`: **7.3.0-rc4**
- Function lives in `drivers/scsi/ibmvscsi/ibmvfc-core.c` (file split
  after this commit)
- `git merge-base --is-ancestor 0122eab60b151 HEAD` → YES (landed in
  **v7.3-rc1**)
- Current `ibmvfc_tgt_implicit_logout_and_del` already has the NULL
  check (4530–4536)
- The hole existed from v6.7 until v7.3-rc1; this lineage had it and now
  has the fix
- `CONFIG_SCSI_IBMVFC` depends on `PPC_PSERIES && SCSI`

Record: [code path present in this tree] [bug from v6.7; fix already on
this HEAD]

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Against this HEAD the original diff would not apply as-is (`ibmvfc.c` →
`ibmvfc-core.c`, NVMe churn). Against a pre-split tree matching
v6.7–v7.2, the hunk is a clean 8-line insert next to the sibling.

Record: [clean on pre-split ibmvfc.c; this HEAD already contains the
equivalent]

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
This exact fix is already an ancestor. Sibling NULL check from
b39f2d10b86d0 is also here.

Record: [this fix already present; no alternate incomplete fix]

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

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: [SCSI ibmvfc / IBM POWER Virtual FC] [IMPORTANT for pseries
guests, not core-universal]

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Mature client driver; recent NVMe/FC work. This NULL check is a pre-
existing SCSI-path bug, not NVMe enablement.

Record: [mature; this fix is independent of NVMe feature work]

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

**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: [platform-specific: PPC_PSERIES Virtual FC; enterprise POWER
VMs]

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record: [target delete / implicit LOGO while reserved event pool empty]
[uncommon but real] [not a syscall smash; storage path loss on the
guest]

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record: [NULL deref in ibmvfc_send_event → oops] [CRITICAL/HIGH]

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Benefit: avoid host oops during target logout/delete. Risk: 8 lines,
error path only; ACTION_NONE is a no-op from LOGOUT_RPORT but send-
failure already recovers via reset/delete. No API change.

Record: [high benefit vs low risk]

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

**Step 9.1: COMPILE THE EVIDENCE**

FOR:
- Real NULL deref: `ibmvfc_send_event` uses `evt` without a check
- Incomplete 2023 call-site update left only `and_del` unguarded
- 8-line clone of the proven sibling path (thread count, kref, host
  reset)
- Author is the ibmvfc owner; SCSI maintainer applied it
- Cover letter calls this a pre-existing bug, not NVMe feature
- Reachable on IBM Virtual FC target delete (production POWER path)

AGAINST:
- Bundled as 03/33 of a large NVMe series (the patch itself is
  independent)
- No Fixes:/Cc:stable/user report (absence is expected)
- `ACTION_NONE` does not stick from `LOGOUT_RPORT`; `DEL_RPORT` would
  match the send-fail arm
- This HEAD already contains the commit (v7.3-rc1); original file name
  has changed

UNRESOLVED:
- Could not fetch lore.kernel.org HTML (403); used b4 mbox instead
- No stable@ discussion found

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — mirrors sibling; applied by
   SCSI maintainer
2. Fixes a real bug that affects users? **PASS** — oops on target delete
   if reserved events are gone
3. Important issue? **PASS** — NULL deref / oops
4. Small and contained? **PASS** — +8 lines, one function
5. No new features or APIs? **PASS**
6. Can apply to the local tree? **PASS** for this lineage (code exists;
   equivalent already in tree). A naive apply of the original `ibmvfc.c`
   diff onto current split sources would not be needed here.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: [none; ordinary crash fix]

**Step 9.4: MAKE YOUR DECISION**
This tree is Linux **7.3-rc4**. The ibmvfc client, `and_del`, and NULL-
returning event allocator are all here. The bug is a missed NULL check
that oopses in `ibmvfc_send_event`. The patch is small, matches existing
recovery, and does not pull in NVMe/FC. The ACTION_NONE no-op is a minor
state-machine nit, not a reason to withhold a crash fix.

------------------------------------------------
What the commit solves for stable users
------------------------------------------------
On IBM POWER Virtual FC, deleting a target does an implicit logout. If
the reserved event pool is empty, allocation returns NULL. The sibling
logout path handled that; the delete path did not, so the host work
thread would oops. Users see a kernel crash during path loss / target
teardown rather than a host reset.

------------------------------------------------
Stable rules / risk vs benefit
------------------------------------------------
Meets the rules: real oops, tiny, no features. Benefit is crash
avoidance on a production pseries driver. Risk is low; recovery matches
the sibling. Do not backport the rest of the 33-patch NVMe series with
it.

------------------------------------------------
Concerns
------------------------------------------------
`ACTION_NONE` is ignored from `LOGOUT_RPORT`; `DEL_RPORT` would be the
closer match to the send-failure arm. Still prevents the oops. On this
7.3-rc4 tree the fix is already present (`0122eab60b151`); that is not
“already selected by the pipeline,” it is the mainline landing. The
driver code this commit exists to protect is in this tree.

Verification:
- [Phase 1] Subject/tags: scsi: ibmvfc NULL evt check; SOB Tyrel
  Datwyler + Martin K. Petersen; Link msgid 20260723000149.969416-4; no
  Fixes/Reported-by
- [Phase 2] Diff: +8 in `ibmvfc_tgt_implicit_logout_and_del` only
- [Phase 2] `__ibmvfc_get_event` can return NULL (ibmvfc-core.c
  1615–1630); helper returns that NULL (4424–4427); `ibmvfc_send_event`
  derefs at 1787
- [Phase 2] `ibmvfc_set_tgt_action`: LOGOUT_RPORT allows only
  LOGOUT_RPORT_WAIT or DEL_RPORT (531–537)
- [Phase 3] and_del from ed830385a2b1f (v5.7-rc1); incomplete sweep
  b39f2d10b86d0 (v6.7-rc1); this fix 0122eab60b151 (v7.3-rc1)
- [Phase 3] `git merge-base --is-ancestor b39f2d10b86d0 HEAD` YES;
  `0122eab60b151` YES
- [Phase 3] After b39f2d10b86d0, and_del still called
  `ibmvfc_send_event(evt)` with no NULL check
- [Phase 4] `b4 dig -c 0122eab60b151`: v2 03/33 NVMe/FC series; cover
  letter lists this as a pre-existing NULL deref
- [Phase 4] `b4 dig -w`: linux-scsi, linuxppc-dev, James Bottomley,
  Martin Petersen, Brian King
- [Phase 4] `b4 dig -m`: Martin applied to 7.3/scsi-staging; sashiko-bot
  ACTION_NONE comment; no human NAK
- [Phase 4] lore HTML fetch 403; WebSearch found no stable@ thread for
  this subject
- [Phase 5] Caller: `ibmvfc_del_tgt` → TGT_DEL work → `job_step`
- [Phase 6] `git describe HEAD` = v7.3-rc4-27-gf0100363d8c37;
  kernelversion 7.3.0-rc4; NULL check present at ibmvfc-core.c 4530–4536
- [Phase 7] CONFIG_SCSI_IBMVFC: PPC_PSERIES Virtual FC client
- [Phase 8] Failure mode: NULL deref oops; severity HIGH/CRITICAL
- UNVERIFIED: human-tested repro on hardware (author analysis +
  maintainer apply only)

**YES**

 drivers/scsi/ibmvscsi/ibmvfc.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 8d7c304636d99..63cc569284ded 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -4403,6 +4403,14 @@ static void ibmvfc_tgt_implicit_logout_and_del(struct ibmvfc_target *tgt)
 	evt = __ibmvfc_tgt_get_implicit_logout_evt(tgt,
 						   ibmvfc_tgt_implicit_logout_and_del_done);
 
+	if (!evt) {
+		vhost->discovery_threads--;
+		ibmvfc_set_tgt_action(tgt, IBMVFC_TGT_ACTION_NONE);
+		kref_put(&tgt->kref, ibmvfc_release_tgt);
+		__ibmvfc_reset_host(vhost);
+		return;
+	}
+
 	ibmvfc_set_tgt_action(tgt, IBMVFC_TGT_ACTION_LOGOUT_RPORT_WAIT);
 	if (ibmvfc_send_event(evt, vhost, default_timeout)) {
 		vhost->discovery_threads--;
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] scsi: smartpqi: Add new PCI device-ids

[Sasha Levin]

From: David Strahan <David.Strahan@microchip.com>

[ Upstream commit 1a220e6e87a31c2572cd07ff47023e5cd92ac80f ]

All PCI ID entries in Hex.

Add PCI IDs for Hurray Data controllers:
                                            VID  / DID  / SVID / SDID
                                            ----   ----   ----   ----
                                            9005 / 028f / 207d / 4246
                                            9005 / 028f / 207d / 4256
                                            9005 / 028f / 207d / 4356
                                            9005 / 028f / 207d / 4940
                                            9005 / 028f / 207d / 4a46

Add PCI IDs for ZTE controllers:
                                            VID  / DID  / SVID / SDID
                                            ----   ----   ----   ----
                                            9005 / 028f / 1cf2 / 5451
                                            9005 / 028f / 1cf2 / 5452
                                            9005 / 028f / 1cf2 / 5453

Add PCI ID for Ramaxel controller:
                                            VID  / DID  / SVID / SDID
                                            ----   ----   ----   ----
                                            9005 / 028f / 1f3f / 0670

Signed-off-by: David Strahan <david.strahan@microchip.com>
Reviewed-by: Don Brace <don.brace@microchip.com>
Link: https://lore.kernel.org/linux-scsi/20260722220401.6357-1-david.strahan@microchip.com/
Link: https://patch.msgid.link/20260722220401.6357-4-david.strahan@microchip.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Connection lost, reconnecting to https://agentn.us.api5.cursor.sh
(attempt 1)...
Retry attempt 1...
## Phase 1: Commit message forensics

**Step 1.1 — Subject**
- Record: `[scsi: smartpqi] [Add] new PCI device-ids for Hurray Data,
  ZTE, and Ramaxel OEM boards`

**Step 1.2 — Tags**
- Record:
  - `Reviewed-by: Don Brace <don.brace@microchip.com>` (listed smartpqi
    maintainer in MAINTAINERS)
  - `Link: https://lore.kernel.org/linux-
    scsi/20260722220401.6357-1-david.strahan@microchip.com/` (cover
    letter)
  - `Link: https://patch.msgid.link/20260722220401.6357-4-
    david.strahan@microchip.com/` (this patch)
  - `Signed-off-by: David Strahan <david.strahan@microchip.com>`
  - `Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>`
    (SCSI maintainer)
  - No `Fixes:`, no `Reported-by:`, no `Cc: stable` (absence expected)
  - Ignore any pipeline `Signed-off-by: Sasha Levin` / `[Upstream commit
    ...]` markers

**Step 1.3 — Body**
- Record: Adds nine `PCI_DEVICE_SUB` entries (VID `9005` / DID `028f`)
  for:
  - Hurray Data SVID `207d`: SDIDs `4246`, `4256`, `4356`, `4940`,
    `4a46`
  - ZTE SVID `1cf2`: SDIDs `5451`, `5452`, `5453`
  - Ramaxel SVID `1f3f`: SDID `0670`
- Symptom/failure mode: those OEM SKUs are not in the explicit ID table,
  so they only bind via the `PCI_ANY_ID` wildcard. With
  `disable_device_id_wildcards=1`, probe returns `-ENODEV`.
- Version info: submitted against Martin Petersen’s `7.2/scsi-queue`;
  applied to `7.3/scsi-staging` / `7.3/scsi-queue`.
- Root cause: missing OEM subsystem IDs, not a logic bug.

**Step 1.4 — Hidden bug fix?**
- Record: Not a disguised crash/UAF fix. Cover letter says “No
  functional changes.” It is still a hardware-enablement ID table
  update, which is an explicit stable exception.

## Phase 2: Diff analysis

**Step 2.1 — Inventory**
- Record: `drivers/scsi/smartpqi/smartpqi_init.c` only; `+36 / -0`.
  Function/object: `pqi_pci_id_table[]`. Surgical, single-file.

**Step 2.2 — Flow change**
- Record: Before: those nine subsystem IDs were absent; match fell
  through to the table’s `PCI_ANY_ID` catch-all. After: they match
  specific `PCI_DEVICE_SUB` rows first. No probe/remove/ioctl logic
  changes.

**Step 2.3 — Bug mechanism**
- Record: Category **hardware workaround / device ID addition**. Not
  UAF, leak, race, etc.

**Step 2.4 — Fix quality**
- Record: Obviously correct copies of adjacent `PCI_DEVICE_SUB` rows. No
  `driver_data`. No API or locking change. Regression risk is negligible
  (table grows; PCI match still first-match). Duplicate IDs were grepped
  and are not present.

## Phase 3: Git history

**Step 3.1 — Blame / introduction**
- Record: Driver added in `6c223761eb548` (2016-08-12), `smartpqi:
  initial commit of Microsemi smartpqi driver`. Catch-all
  `PCI_DEVICE_SUB(..., PCI_ANY_ID, PCI_ANY_ID)` is from that same
  commit. Vendor blocks already exist: Hurray `0x207d` (e.g.
  `48e6b7e708029`, `01b8bdddcfab0`), ZTE `0x1cf2` (since
  `09d9968a8eff8`, 2021), Ramaxel `0x1f3f` (`01b8bdddcfab0` /
  `dab5378485f60`).

**Step 3.2 — Fixes: tag**
- Record: None. Not applicable.

**Step 3.3 — File history**
- Record: Recent same-file work is a 4-patch series:
  1. `225548863f0a2` AIO retry marker
  2. `c64b2ab2ff516` `CCISS_BIG_PASSTHRU` ioctl
  3. `1a220e6e87a31` this ID patch
  4. `913337c48e6aa` version string
- This patch only inserts ID rows; it does not use the ioctl or AIO
  changes. Standalone.

**Step 3.4 — Author**
- Record: David Strahan is a regular Microchip smartpqi contributor
  (many prior PCI ID commits). Reviewed by Don Brace, the listed
  maintainer.

**Step 3.5 — Prerequisites**
- Record: Needs existing `pqi_pci_id_table` and neighboring `0x207d` /
  `0x1cf2` / `0x1f3f` rows for a clean apply. Those exist in this
  checkout. No new helpers or structs.

## Phase 4: Mailing list / external

**Step 4.1 — Original discussion**
- Record: `b4 dig -c 1a220e6e87a31` → https://patch.msgid.link/202607222
  20401.6357-4-david.strahan@microchip.com
- Cover: `[PATCH v1 0/4] smartpqi: fixes and updates for 2.1.42-011`
- This patch is `[PATCH v1 3/4] smartpqi: add new pci device-ids`
- `b4 dig -a` shows one v1 of this ID patch (other “v2/v3/v4” labels are
  sibling patches in the same send, not later ID-table revisions).
  Applied version is that v1.
- Martin K. Petersen: “Applied to 7.3/scsi-staging, thanks!” then
  “Applied to 7.3/scsi-queue” listing `[3/4] ... 1a220e6e87a3`. No NAKs,
  no stable nomination, no risk comments on the ID patch. Thread replies
  were about patches 1/4 and 2/4, not IDs.

**Step 4.2 — Recipients (`b4 dig -w`)**
- Record: David Strahan, `linux-scsi@vger.kernel.org`, Don Brace.
  Correct list and maintainer.

**Step 4.3 — Bug report**
- Record: No `Reported-by` / bugzilla / syzbot. Hardware enablement from
  the vendor.

**Step 4.4 — Series**
- Record: Patches 1–2 are independent (retry-marker callback; new
  ioctl). Patch 4 is a version string. This ID commit does not depend on
  them.

**Step 4.5 — Stable list**
- Record: lore.kernel.org/stable fetch returned HTTP 403. mbox has no
  “stable” / “NAK” hits. UNVERIFIED: whether anyone already asked
  stable@ about this hash.

## Phase 5: Code semantics

**Step 5.1 — Functions**
- Record: `pqi_pci_id_table` only (not a function). Consumed by
  `MODULE_DEVICE_TABLE(pci, pqi_pci_id_table)` and
  `pqi_pci_driver.id_table`.

**Step 5.2 — Callers**
- Record: `pci_register_driver(&pqi_pci_driver)` from `pqi_init()`.
  Probe is `pqi_pci_probe()`. Path is PCI enumeration / module autoload,
  not a syscall hot path.

**Step 5.3 — Callees**
- Record: Probe uses the matched `pci_device_id`. Relevant logic:

```9468:9478:drivers/scsi/smartpqi/smartpqi_init.c
        if (pqi_disable_device_id_wildcards &&
                id->subvendor == PCI_ANY_ID &&
                id->subdevice == PCI_ANY_ID) {
                dev_warn(&pci_dev->dev,
                        "controller not probed because device ID
wildcards are disabled\n");
                return -ENODEV;
        }

        if (id->subvendor == PCI_ANY_ID || id->subdevice == PCI_ANY_ID)
                dev_warn(&pci_dev->dev,
                        "controller device ID matched using
wildcards\n");
```

**Step 5.4 — Reachability**
- Record: Yes. Plug-in / boot with `CONFIG_SCSI_SMARTPQI`. Default:
  catch-all already binds `9005:028f`. With
  `disable_device_id_wildcards=1`, only explicit rows bind — these nine
  SKUs need the new entries.

**Step 5.5 — Similar patterns**
- Record: Same file has a long history of OEM ID additions (`Add new PCI
  IDs`, Hurray/ZTE/Ramaxel). This matches that pattern.

## Phase 6: Local tree

**Step 6.1 — Does the target code exist here?**
- Record: Local tree is **v7.3-rc4** (`7.3.0-rc4`).
  `drivers/scsi/smartpqi/` exists (`CONFIG_SCSI_SMARTPQI`). Neighboring
  Hurray/ZTE/Ramaxel rows exist. The nine IDs are already in the table
  because `1a220e6e87a31` is an ancestor of HEAD. The code this commit
  touches is present.

**Step 6.2 — Backport difficulty**
- Record: In this tree: already applied / would apply cleanly. Older
  stables may need context tweak if some neighboring IDs are missing;
  still a mechanical table insert.

**Step 6.3 — Related fixes already here?**
- Record: Earlier Hurray/ZTE/Ramaxel IDs are here; these nine SDIDs were
  new in this commit. No alternate fix.

## Phase 7: Subsystem context

**Step 7.1**
- Record: SCSI hardware driver `drivers/scsi/smartpqi/`. Criticality
  **IMPORTANT** (storage RAID/HBA on servers; not core mm/VFS). Not
  staging.

**Step 7.2**
- Record: Actively maintained by Microchip; frequent ID and bugfix
  updates. Driver itself is mature (2016).

## Phase 8: Impact and risk

**Step 8.1 — Who is affected**
- Record: Driver-specific: Hurray Data, ZTE, and Ramaxel boards using
  Adaptec2/Microchip `9005:028f`.

**Step 8.2 — Trigger**
- Record: Device present at enumeration. Common for those machines.
  Unprivileged users do not trigger it; missing IDs mean the RAID
  controller never binds (especially with wildcards disabled).

**Step 8.3 — Failure mode**
- Record: Controller not claimed (or only via wildcard, which some
  deployments disable). Severity **MEDIUM** as a “bug,” **HIGH** as
  hardware enablement for those boxes (boot disks can sit unused). Not a
  panic/UAF.

**Step 8.4 — Risk vs benefit**
- Record: Benefit: OEM HBAs work / are explicitly supported, including
  `disable_device_id_wildcards=1`. Risk: very low (36-line ID table
  only). Ratio strongly favors backport.

## Phase 9: Synthesis

**Step 9.1 — Evidence**

For:
- Explicit stable exception: PCI IDs on an existing driver
- Nine OEM SKUs; same VID/DID as the rest of the table
- `disable_device_id_wildcards` makes explicit IDs actually required
- 36 lines, one file, no logic/API change
- Reviewed by Don Brace; applied by Martin K. Petersen
- Standalone vs the rest of the 4-patch series
- Driver and vendor blocks exist in this tree

Against:
- Cover letter: “No functional changes”
- Catch-all already matches `9005:028f` when wildcards stay enabled
- Not a crash/security/corruption fix
- No `Cc: stable` (not a negative per the review rules)

Unresolved:
- Stable@ search 403; no independent confirmation of a prior stable
  request

**Step 9.2 — Stable rules**
1. Obviously correct and tested? **PASS** (mechanical ID rows;
   maintainer Reviewed-by)
2. Real user-facing issue? **PASS** (hardware bind / explicit support)
3. Important? **PASS** under the PCI-ID exception (storage HBA
   enablement)
4. Small and contained? **PASS** (+36, one table)
5. No new features/APIs? **PASS** (IDs only; ioctl/version patches are
   separate)
6. Can apply to this tree? **PASS** (driver + table present; insertion
   points exist)

**Step 9.3 — Exception**
- Record: **NEW DEVICE IDs** to an existing driver.

**Step 9.4 — Decision**
This is the standard PCI ID stable case. It should be backported to this
tree: the smartpqi driver and ID table are here, the change is self-
contained, and it enables known OEM controllers (including when wildcard
matching is disabled).

### What it solves for stable users
Without these rows, Hurray/ZTE/Ramaxel `9005:028f` boards only match the
wildcard. Default kernels still probe them; kernels using
`disable_device_id_wildcards` refuse them. Listing the IDs is how this
driver declares supported SKUs and how those machines get a bound HBA.

### Risk vs benefit
Benefit is hardware enablement; risk is essentially nil. No dependency
on the AIO or `CCISS_BIG_PASSTHRU` patches.

Verification:
- [Phase 1] Parsed tags: Reviewed-by Don Brace; Links to cover
  `...6357-1` and patch `...6357-4`; SOBs Strahan and Martin Petersen;
  no Fixes/Reported-by/Cc:stable
- [Phase 2] Diff: +36 in `pqi_pci_id_table` only; nine `PCI_DEVICE_SUB`
  entries; grep showed no duplicate SDIDs
- [Phase 3] `git describe HEAD` → `v7.3-rc4-27-gf0100363d8c37`; `make
  kernelversion` → `7.3.0-rc4`
- [Phase 3] Commit SHA `1a220e6e87a31`; `git merge-base --is-ancestor
  1a220e6e87a31 HEAD` succeeded
- [Phase 3] Driver intro `6c223761eb548` (2016); catch-all from that
  commit; prior Hurray `48e6b7e708029` / `01b8bdddcfab0`; ZTE
  `09d9968a8eff8`; Ramaxel `dab5378485f60`
- [Phase 3] Parent of ID commit still has neighbors `0x4240`, `0x4840`,
  `0x544f`, `0x54da`, `0x0610`
- [Phase 4] `b4 dig -c 1a220e6e87a31` → msgid `20260722220401.6357-4`;
  `-w` CC linux-scsi + Don Brace; `-a` single v1 of this ID patch; `-m`
  saved `/tmp/smartpqi-ids.mbox`
- [Phase 4] Cover letter: “Adds PCI IDs … No functional changes.”
  Martin: applied 1/4–4/4 to 7.3/scsi-queue. No NAK on IDs
- [Phase 4] lore.kernel.org WebFetch 403; stable@ discussion UNVERIFIED
- [Phase 5] `pqi_pci_probe` wildcard-disable path verified at lines
  9468–9478; `module_param_named(disable_device_id_wildcards, ...)`
- [Phase 6] Grep of current `smartpqi_init.c` found all nine new IDs;
  `CONFIG_SCSI_SMARTPQI` in `drivers/scsi/smartpqi/Kconfig`
- [Phase 7] MAINTAINERS: Don Brace, Supported
- [Phase 8] Failure: `-ENODEV` when wildcards disabled; otherwise
  wildcard match + warning
- UNVERIFIED: whether older stable branches need context adjustment
  around missing neighboring IDs (not this checkout)

**YES**

 drivers/scsi/smartpqi/smartpqi_init.c | 36 +++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/drivers/scsi/smartpqi/smartpqi_init.c b/drivers/scsi/smartpqi/smartpqi_init.c
index 88cffb1fb59ce..3f5fabf723c3e 100644
--- a/drivers/scsi/smartpqi/smartpqi_init.c
+++ b/drivers/scsi/smartpqi/smartpqi_init.c
@@ -10152,10 +10152,30 @@ static const struct pci_device_id pqi_pci_id_table[] = {
 		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
 			       0x207d, 0x4240)
 	},
+	{
+		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
+			       0x207d, 0x4246)
+	},
+	{
+		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
+			       0x207d, 0x4256)
+	},
+	{
+		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
+			       0x207d, 0x4356)
+	},
 	{
 		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
 			       0x207d, 0x4840)
 	},
+	{
+		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
+			       0x207d, 0x4940)
+	},
+	{
+		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
+			       0x207d, 0x4a46)
+	},
 	{
 		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
 			       PCI_VENDOR_ID_ADVANTECH, 0x8312)
@@ -10340,6 +10360,18 @@ static const struct pci_device_id pqi_pci_id_table[] = {
 		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
 			       0x1cf2, 0x544f)
 	},
+	{
+		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
+			       0x1cf2, 0x5451)
+	},
+	{
+		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
+			       0x1cf2, 0x5452)
+	},
+	{
+		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
+			       0x1cf2, 0x5453)
+	},
 	{
 		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
 			       0x1cf2, 0x54da)
@@ -10380,6 +10412,10 @@ static const struct pci_device_id pqi_pci_id_table[] = {
 		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
 			       0x1f3f, 0x0610)
 	},
+	{
+		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
+			       0x1f3f, 0x0670)
+	},
 	{
 		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
 			       PCI_VENDOR_ID_LENOVO, 0x0220)
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] scsi: ibmvfc: check for NULL evt in implicit LOGO and target delete path

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] scsi: ibmvfc: invalid state transition in ibmvfc_tgt_implicit_logout_and_del()
--

commit 99489de7e63442e984a1136b57de120f99e8b4e7
Author: Tyrel Datwyler <tyreld@linux.ibm.com>

scsi: ibmvfc: check for NULL evt in implicit LOGO and target delete path

This commit adds a NULL check for the event returned by
__ibmvfc_tgt_get_implicit_logout_evt() in ibmvfc_tgt_implicit_logout_and_del()
before passing it to ibmvfc_send_event().

Link: https://patch.msgid.link/20260723000149.969416-4-tyreld@linux.ibm.com

> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
> index 228daffb286de..66fe30b04b6a5 100644
> --- a/drivers/scsi/ibmvscsi/ibmvfc.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c
> @@ -4403,6 +4403,14 @@ static void ibmvfc_tgt_implicit_logout_and_del(struct ibmvfc_target *tgt)
>  	evt = __ibmvfc_tgt_get_implicit_logout_evt(tgt,
>  						   ibmvfc_tgt_implicit_logout_and_del_done);
>  
> +	if (!evt) {
> +		vhost->discovery_threads--;
> +		ibmvfc_set_tgt_action(tgt, IBMVFC_TGT_ACTION_NONE);

[Severity: Medium]
Should this pass IBMVFC_TGT_ACTION_DEL_RPORT instead of
IBMVFC_TGT_ACTION_NONE?

ibmvfc_tgt_implicit_logout_and_del() is installed as tgt->job_step in
ibmvfc_del_tgt() when tgt->action is set to IBMVFC_TGT_ACTION_LOGOUT_RPORT:

drivers/scsi/ibmvscsi/ibmvfc.c:ibmvfc_del_tgt() {
	if (!ibmvfc_set_tgt_action(tgt, IBMVFC_TGT_ACTION_LOGOUT_RPORT)) {
		tgt->job_step = ibmvfc_tgt_implicit_logout_and_del;
		tgt->init_retries = 0;
	}
}

and ibmvfc_do_work() only invokes it while tgt->action is
IBMVFC_TGT_ACTION_LOGOUT_RPORT:

drivers/scsi/ibmvscsi/ibmvfc.c:ibmvfc_do_work() {
	case IBMVFC_HOST_ACTION_TGT_DEL:
	case IBMVFC_HOST_ACTION_TGT_DEL_FAILED:
		list_for_each_entry(tgt, &vhost->targets, queue) {
			if (tgt->action == IBMVFC_TGT_ACTION_LOGOUT_RPORT) {
				tgt->job_step(tgt);
				break;
			}
		}

		if (ibmvfc_dev_logo_to_do(vhost)) {
			spin_unlock_irqrestore(vhost->host->host_lock, flags);
			return;
		}
}

However, in ibmvfc_set_tgt_action(), when tgt->action is
IBMVFC_TGT_ACTION_LOGOUT_RPORT, only transitions to
IBMVFC_TGT_ACTION_LOGOUT_RPORT_WAIT or IBMVFC_TGT_ACTION_DEL_RPORT are
permitted:

drivers/scsi/ibmvscsi/ibmvfc.c:ibmvfc_set_tgt_action() {
	switch (tgt->action) {
	case IBMVFC_TGT_ACTION_LOGOUT_RPORT:
		if (action == IBMVFC_TGT_ACTION_LOGOUT_RPORT_WAIT ||
		    action == IBMVFC_TGT_ACTION_DEL_RPORT) {
			tgt->action = action;
			rc = 0;
		}
		break;
}

Passing IBMVFC_TGT_ACTION_NONE here returns -EINVAL without changing
tgt->action, leaving the target in IBMVFC_TGT_ACTION_LOGOUT_RPORT instead
of transitioning it to IBMVFC_TGT_ACTION_DEL_RPORT like the other error
paths in ibmvfc_tgt_implicit_logout_and_del(). As a result,
ibmvfc_dev_logo_to_do(vhost) continues to return 1 and blocks rport
deletion in IBMVFC_HOST_ACTION_TGT_DEL / IBMVFC_HOST_ACTION_TGT_DEL_FAILED
(including during adapter removal when vhost->state is IBMVFC_HOST_OFFLINE).

> +		kref_put(&tgt->kref, ibmvfc_release_tgt);
> +		__ibmvfc_reset_host(vhost);
> +		return;
> +	}
> +
>  	ibmvfc_set_tgt_action(tgt, IBMVFC_TGT_ACTION_LOGOUT_RPORT_WAIT);
>  	if (ibmvfc_send_event(evt, vhost, default_timeout)) {
>  		vhost->discovery_threads--;

I hope this helps!
 Let me know if you need any further details.

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