[PATCH AUTOSEL 6.18-6.12] PCI: plda: Protect root bus removal with rescan lock

[PATCH AUTOSEL 6.18-6.12] PCI: plda: Protect root bus removal with rescan lock

[Sasha Levin]

From: Hans Zhang <18255117159@163.com>

[ Upstream commit 4e4f9745f016c1631d00a4035b06f6e75d449e01 ]

Hold the pci_rescan_remove_lock lock while stopping and removing a root bus
to avoid racing with concurrent rescan or hotplug operations triggered via
sysfs.  Such races may lead to use-after-free issues or system crashes.

Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260521161822.132996-10-18255117159@163.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: PCI: plda: Protect root bus removal with
rescan lock

**Local tree:** `v6.18.44-1-g2736c32da98b9` (Linux 6.18.44)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
**Record:** `[PCI: plda]` `[Protect]` — Add `pci_rescan_remove_lock`
protection around root bus teardown in the PLDA PCIe host driver.

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
**Record:**
- **Fixes:** — not present (expected for manual review)
- **Reported-by:** — none
- **Tested-by:** — none
- **Reviewed-by:** — none in this commit (series cover references
  sashiko-bot review)
- **Acked-by:** — none
- **Link:** `https://patch.msgid.link/20260521161822.132996-10-
  18255117159@163.com`
- **Cc: stable:** — none
- **Signed-off-by:** Hans Zhang, Manivannan Sadhasivam, Bjorn Helgaas
  (ignore any pipeline-added SOBs)

Notable: No syzbot/user crash report; issue identified by code-review
pattern (series cover letter cites sashiko-bot).

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
**Record:**
- **Bug:** `plda_pcie_host_deinit()` calls `pci_stop_root_bus()` /
  `pci_remove_root_bus()` without holding `pci_rescan_remove_lock`.
- **Symptom:** Race with concurrent sysfs-triggered PCI rescan or
  hotplug/remove → use-after-free or system crash.
- **Root cause:** Missing lock acquisition that other PCI host drivers
  already use.
- **Version info:** None in commit message.

### Step 1.4: DETECT HIDDEN BUG FIXES
**Record:** Not disguised — this is an explicit synchronization/race
fix, not cleanup or optimization.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
**Record:**
- **File:** `drivers/pci/controller/plda/pcie-plda-host.c` (+2 lines)
- **Function:** `plda_pcie_host_deinit()`
- **Scope:** Single-file, surgical fix (2 insertions)

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Record:**
- **Before:** Root bus stop/remove ran unlocked during driver teardown.
- **After:** `pci_lock_rescan_remove()` held for the entire
  `pci_stop_root_bus()` + `pci_remove_root_bus()` sequence, then
  unlocked.
- **Path affected:** Platform driver remove / module unload error path
  via `starfive_pcie_remove()` → `plda_pcie_host_deinit()`.

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Record:** **Category:** Synchronization / race condition.

**Mechanism:** Sysfs rescan/remove paths (`rescan_store`,
`dev_rescan_store`, `bus_rescan_store`, `remove_store`) all take
`pci_lock_rescan_remove()` (verified in `drivers/pci/pci-sysfs.c`).
`pci_stop_root_bus()` / `pci_remove_root_bus()` tear down the same
bus/device lists without that lock in `plda_pcie_host_deinit()`,
creating a concurrent teardown vs. rescan/remove window.

### Step 2.4: ASSESS THE FIX QUALITY
**Record:**
- **Quality:** Obviously correct; matches `pci_host_common_remove()`,
  `mtk_pcie_remove()`, `pci_aardvark` remove, etc.
- **Risk:** Very low — standard mutex pair, no API change, no logic
  change beyond serialization.
- **Red flags:** None.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
**Record:**
- Buggy `pci_stop_root_bus()` / `pci_remove_root_bus()` calls introduced
  in **76c9113968079** (`PCI: plda: Add host init/deinit and map bus
  functions`, May 28 2024).
- Present in this 6.18.44 tree without the lock.

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

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
**Record:**
- Part of a 9-patch series (`[PATCH 0/9] PCI: controller: Add missing
  rescan lock around root bus removal`) fixing the same pattern in
  cadence, dwc, altera, brcmstb, iproc, mediatek, rockchip, vmd, and
  plda.
- Cover letter states: *"Each patch is independent and targets a
  specific controller driver."*
- Related precedent: **1d59d474e1cb7** (`PCI: Hold rescan lock while
  adding devices during host probe`) — real NULL deref crash from
  missing rescan lock during concurrent PCI operations.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
**Record:** Hans Zhang authored the full 9-driver series. PCI
maintainers (Bjorn Helgaas) committed related PCI work in this tree. No
Hans Zhang commits currently in this tree's plda path (series not yet
merged here).

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
**Record:** **Standalone.** Only requires existing
`pci_lock_rescan_remove()` / `pci_unlock_rescan_remove()` (present since
**9d16947b75831**, Jan 2014). No structural prerequisites.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
**Record:**
- `b4 dig -c <sha>`: N/A — commit not in this tree.
- Local mbox `20260522_18255117159_pci_controller_add_missing_rescan_loc
  k_around_root_bus_removal.mbx` contains full series.
- Cover letter references sashiko-bot review asking whether unlocked
  root bus removal can race with sysfs rescan/hotplug.
- WebFetch of patch.msgid.link: blocked by anti-bot page (could not read
  live thread).

### Step 4.2: CHECK WHO REVIEWED THE PATCH
**Record:** Cover letter CC'd linux-pci; bot review prompted the series.
Final commit SOBs include Manivannan Sadhasivam and Bjorn Helgaas. Full
maintainer thread not verified live.

### Step 4.3: SEARCH FOR THE BUG REPORT
**Record:** No user crash report or syzbot link for plda specifically.
Issue identified by code-review pattern matching against known PCI
locking requirements.

### Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
**Record:** 9-patch series; each driver patch is independent per cover
letter. Other drivers in this tree (dwc, cadence, altera, etc.) have the
**same unfixed pattern** — this commit only addresses plda.

### Step 4.5: CHECK STABLE MAILING LIST HISTORY
**Record:** Not searched (no stable nomination found in local mbox).
Absence of `Cc: stable` is not a negative signal per review
instructions.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
**Record:** `plda_pcie_host_deinit()` — only function modified.

### Step 5.2: TRACE CALLERS
**Record:**
- **Caller:** `starfive_pcie_remove()` in
  `drivers/pci/controller/plda/pcie-starfive.c` (platform `.remove`
  callback).
- **Context:** Driver unbind, module unload, platform device removal —
  can overlap with root-initiated sysfs PCI operations.

### Step 5.3: TRACE CALLEES
**Record:** `pci_lock_rescan_remove()`, `pci_stop_root_bus()`,
`pci_remove_root_bus()`, `pci_unlock_rescan_remove()`, then
`plda_pcie_irq_domain_deinit()` and optional `host_deinit`.

### Step 5.4: FOLLOW THE CALL CHAIN
**Record:**
- `platform_driver.remove` → `plda_pcie_host_deinit()` → unlocked bus
  teardown.
- Concurrent path: root writes to `/sys/bus/pci/rescan`,
  `/sys/.../remove`, or per-device rescan while StarFive PCIe driver is
  being removed.
- **Reachability:** Requires `CONFIG_PCIE_STARFIVE_HOST` (StarFive
  JH7110 / COMPILE_TEST). Sysfs triggers require root; driver remove can
  also happen during reboot/module unload.

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
**Record:** Same missing-lock pattern exists in dwc, cadence, altera,
brcmstb, iproc, mediatek (non-gen3), rockchip, vmd in this tree.
**Correct pattern** already present in `pci_host_common_remove()`,
`mtk_pcie_remove()` (gen3), `pci_aardvark`, `pci_mvebu`, `pci-hyperv`.

---

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

### Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
**Record:** **YES.** Current code at lines 641–644 of `pcie-plda-
host.c`:

```641:644:drivers/pci/controller/plda/pcie-plda-host.c
void plda_pcie_host_deinit(struct plda_pcie_rp *port)
{
        pci_stop_root_bus(port->bridge->bus);
        pci_remove_root_bus(port->bridge->bus);
```

Bug present since **76c9113968079** (May 2024), well before 6.18.y
branched.

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
**Record:** **Clean apply expected** — 2-line addition with no
surrounding churn in recent plda history. Latest plda-host change:
`882569dca6646`.

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
**Record:** **No** — `git log --grep="plda: Protect root bus"` returned
nothing. Fix not yet in this tree.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
**Record:** **Subsystem:** `drivers/pci/controller/plda` (PCI host
controller). **Criticality:** IMPORTANT — PCI core synchronization;
crash/UAF on affected hardware.

### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
**Record:** PLDA code actively maintained (MSI domain switch, affinity,
microchip integration in 6.17–6.18). StarFive driver added May 2024,
merged via pci-v6.12-changes.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
**Record:** **Platform-specific** — users of `CONFIG_PCIE_STARFIVE_HOST`
(StarFive JH7110 RISC-V boards). Microchip PLDA users go through
`pci_host_common_remove()` which already holds the lock.

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
**Record:**
- **Trigger:** Concurrent PLDA host driver removal and sysfs PCI
  rescan/remove on the same bus hierarchy.
- **Likelihood:** Uncommon but realistic (admin scripts, hotplug
  testing, driver rebind during PCI maintenance).
- **Unprivileged trigger:** No direct userspace trigger without
  root/CAP_SYS_ADMIN for sysfs PCI ops.

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
**Record:** **Use-after-free / kernel crash** — severity **HIGH**
(potential **CRITICAL** on affected systems). Matches documented PCI
subsystem race class; similar missing-lock bug caused a real oops in
**1d59d474e1cb7**.

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
**Record:**
- **Benefit:** Prevents crashes/UAF on StarFive JH7110 stable
  deployments during driver teardown.
- **Risk:** Minimal — 2-line lock pair, established pattern, no behavior
  change except correct serialization.
- **Ratio:** Strong benefit, negligible risk.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backport:**
- Real synchronization bug in existing code path
- Documented PCI race class with UAF/crash consequences
- 2-line fix matching multiple in-tree precedents
- Bug present since `plda_pcie_host_deinit()` was added (2024)
- Standalone, applies cleanly to 6.18.44
- PCI maintainer sign-off (Bjorn Helgaas)
- Prior stable-worthy precedent: **1d59d474e1cb7** (rescan lock crash
  fix)

**AGAINST backport:**
- No explicit user crash report for plda
- Affects niche embedded platform (StarFive JH7110 only in this tree)
- Sysfs race requires privileged access

**UNRESOLVED:**
- Full lore.kernel.org review thread (WebFetch blocked)
- Whether commit has landed in mainline (not in this checkout)

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — matches established in-tree
   pattern; no Tested-by but fix is trivially verifiable.
2. Fixes a real bug? **PASS** — missing lock on bus teardown vs. sysfs
   rescan/remove.
3. Important issue? **PASS** — UAF/crash (HIGH severity).
4. Small and contained? **PASS** — 2 lines, 1 function.
5. No new features or APIs? **PASS** — synchronization only.
6. Can apply to local tree? **PASS** — buggy code confirmed present;
   infrastructure exists.

### Step 9.3: EXCEPTION CATEGORIES
**Record:** None (not a quirk, device ID, DT, build, or docs fix).
Standard bug fix.

### Step 9.4: DECISION RATIONALE

For Linux **6.18.y**, `plda_pcie_host_deinit()` removes a root PCI bus
without holding `pci_rescan_remove_lock`, while sysfs rescan/remove
paths hold that same lock. This is a known PCI race pattern that can
cause use-after-free and kernel crashes. The fix is a minimal 2-line
addition that mirrors `pci_host_common_remove()` and other corrected
drivers. It is standalone, applies cleanly, and addresses a real
stability issue on StarFive JH7110 systems using
`CONFIG_PCIE_STARFIVE_HOST`.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body from provided commit message
  and local mbox cover letter.
- **[Phase 2]** Read current `pcie-plda-host.c` lines 641–651; confirmed
  2-line lock addition matches diff.
- **[Phase 2]** Read `drivers/pci/remove.c` — `pci_stop_root_bus()` /
  `pci_remove_root_bus()` have no internal lock.
- **[Phase 2]** Read `drivers/pci/pci-sysfs.c` lines 461–541 —
  rescan/remove stores use `pci_lock_rescan_remove()`.
- **[Phase 3]** `git describe HEAD` → v6.18.44; Makefile confirms
  6.18.44.
- **[Phase 3]** `git blame` lines 641–644 → introduced in
  **76c9113968079** (2024-03-28).
- **[Phase 3]** `git show 76c9113968079` — added
  `plda_pcie_host_deinit()`.
- **[Phase 3]** `git show 9d16947b75831` — `pci_lock_rescan_remove()`
  added 2014.
- **[Phase 3]** `git show 1d59d474e1cb7` — precedent crash from missing
  rescan lock.
- **[Phase 3]** `git log --grep="plda: Protect root bus"` — no match
  (fix not in tree).
- **[Phase 4]** Read local mbox `20260522_18255117159_pci_controller_add
  _missing_rescan_lock_around_root_bus_removal.mbx` — series context and
  bot review.
- **[Phase 4]** `b4 dig -c 76c9113968079` — found unrelated plda init
  thread (not this patch).
- **[Phase 4]** WebFetch patch.msgid.link — blocked (UNVERIFIED live
  thread).
- **[Phase 5]** `grep plda_pcie_host_deinit` — single caller:
  `starfive_pcie_remove()`.
- **[Phase 5]** `grep pci_lock_rescan_remove drivers/pci/controller/` —
  confirmed correct pattern in host-common, mtk-gen3, aardvark, mvebu,
  hyperv; missing in plda.
- **[Phase 6]** Buggy code confirmed present in 6.18.44 checkout.
- **[Phase 6]** Read `drivers/pci/controller/plda/Kconfig` — StarFive
  selects `PCIE_PLDA_HOST`; Microchip uses `PCI_HOST_COMMON` (already
  locked).
- **[Phase 7]** `git log --oneline -5 drivers/pci/controller/plda/pcie-
  starfive.c` — driver present since **39b91eb40c6aa** (May 2024).
- **[Phase 8]** Failure mode UAF/crash inferred from commit message, PCI
  probe.c comment (lines 3536–3539), and **1d59d474e1cb7** precedent —
  no plda-specific crash report (UNVERIFIED user impact).

**YES**The git history check finished successfully. It confirmed the
missing lock has been in `plda_pcie_host_deinit()` since commit
`76c9113968079` (May 2024), and that the fix is not yet in this 6.18.44
tree.

**Verdict: YES** — backport this commit. It’s a small, correct race fix
(UAF/crash risk during root bus removal vs. sysfs rescan) that matches
the pattern already used in `pci_host_common_remove()` and similar
drivers.

 drivers/pci/controller/plda/pcie-plda-host.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/controller/plda/pcie-plda-host.c b/drivers/pci/controller/plda/pcie-plda-host.c
index 3c2f683830107..f9a34f323ad8c 100644
--- a/drivers/pci/controller/plda/pcie-plda-host.c
+++ b/drivers/pci/controller/plda/pcie-plda-host.c
@@ -640,8 +640,10 @@ EXPORT_SYMBOL_GPL(plda_pcie_host_init);
 
 void plda_pcie_host_deinit(struct plda_pcie_rp *port)
 {
+	pci_lock_rescan_remove();
 	pci_stop_root_bus(port->bridge->bus);
 	pci_remove_root_bus(port->bridge->bus);
+	pci_unlock_rescan_remove();
 
 	plda_pcie_irq_domain_deinit(port);
 
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-6.12] PCI: plda: Protect root bus removal with rescan lock

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Premature runtime PM suspend during device removal in starfive_pcie_remove() risks system crash.
--

commit deb27e1c30d66425178af3188e74b7f9e994d90f
Author: Hans Zhang <18255117159@163.com>

PCI: plda: Protect root bus removal with rescan lock

This commit adds the pci_rescan_remove_lock around pci_stop_root_bus() and
pci_remove_root_bus() during driver teardown to prevent races with sysfs
rescan or hotplug operations.

Link: https://patch.msgid.link/20260521161822.132996-10-18255117159@163.com

> diff --git a/drivers/pci/controller/plda/pcie-plda-host.c b/drivers/pci/controller/plda/pcie-plda-host.c
> index 3c2f683830107..f9a34f323ad8c 100644
> --- a/drivers/pci/controller/plda/pcie-plda-host.c
> +++ b/drivers/pci/controller/plda/pcie-plda-host.c
> @@ -640,8 +640,10 @@ EXPORT_SYMBOL_GPL(plda_pcie_host_init);
>  
>  void plda_pcie_host_deinit(struct plda_pcie_rp *port)
>  {
> +	pci_lock_rescan_remove();
>  	pci_stop_root_bus(port->bridge->bus);

[Severity: High]
This is a pre-existing issue, but does dropping the runtime PM references
in starfive_pcie_remove() before calling plda_pcie_host_deinit() risk a
system crash?

When the pcie-starfive driver is removed, starfive_pcie_remove() is
executed. This function drops the runtime PM usage count and disables
runtime PM before fully tearing down the child PCI devices:

drivers/pci/controller/plda/pcie-starfive.c:starfive_pcie_remove() {
        ...
        pm_runtime_put(&pdev->dev);
        pm_runtime_disable(&pdev->dev);
        plda_pcie_host_deinit(&pcie->plda);
        ...
}

If child PCI devices are already runtime-suspended, dropping the host
controller's PM reference allows the PM domain to suspend the controller
(e.g., via clock or power gating). Because pm_runtime_disable() is also
called, the controller cannot be runtime-resumed.

Subsequently, plda_pcie_host_deinit() calls pci_stop_root_bus(), which
unbinds the endpoint drivers. When the endpoint drivers' remove callbacks
execute and attempt to access PCI configuration or MMIO space, the accesses
will hit a powered-down bus, which can result in a synchronous external
abort (SError) and a kernel panic.

Should plda_pcie_host_deinit() be called before dropping the runtime PM
references to avoid this?

>  	pci_remove_root_bus(port->bridge->bus);
> +	pci_unlock_rescan_remove();
>  
>  	plda_pcie_irq_domain_deinit(port);

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

[PATCH AUTOSEL 6.18-6.12] PCI: Avoid FLR for MediaTek MT7925 WiFi

[Sasha Levin]

From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>

[ Upstream commit 9f22b92259bb5ac43e2b9007103787d4418fec56 ]

The MediaTek MT7925 WiFi device advertises FLR capability, but it does not
work correctly. This manifests in VFIO passthrough scenarios. Normal VM
operation works fine, including clean shutdown/reboot. However, when the VM
terminates uncleanly (crash, force-off), VFIO attempts to reset the device
before it can be assigned to another VM. Because FLR is broken, the reset
fails, preventing reuse.

This is similar to its predecessor MT7922 (see 81f64e925c29 ("PCI: Avoid
FLR for Mediatek MT7922 WiFi")), but with different symptoms.  The MT7922
issue manifests as config read failures (returning ~0) after FLR. The
MT7925 shows different behavior: config reads work correctly after FLR, but
firmware communication fails.

First VM start with MT7925 works fine:

  mt7925e 0000:08:00.0: ASIC revision: 79250000
  mt7925e 0000:08:00.0: WM Firmware Version: ____000000, Build Time: 20260106153120

After force reset or VM crash, when VFIO attempts FLR to reset the device
for reassignment, firmware initialization fails:

  mt7925e 0000:08:00.0: ASIC revision: 79250000
  mt7925e 0000:08:00.0: Message 00000010 (seq 1) timeout
  mt7925e 0000:08:00.0: Failed to get patch semaphore
  [Repeats with increasing sequence numbers 2-10]
  mt7925e 0000:08:00.0: hardware init failed

The driver cannot acquire the patch semaphore needed for firmware
initialization, indicating that FLR does not properly reset the firmware
state. The device remains in this broken state until physical power cycle.

Disable FLR for MT7925 so the PCI core falls back to other reset methods,
e.g., Secondary Bus Reset, which successfully resets the device and allows
reinitialization for VFIO passthrough reuse.

Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260522070646.203115-1-jtornosm@redhat.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:** `[PCI] [avoid] Avoid FLR for MediaTek MT7925 WiFi — disable
broken Function Level Reset so PCI core falls back to Secondary Bus
Reset`

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Jose Ignacio Tornos Martinez
  `<jtornosm@redhat.com>` (author)
- **Signed-off-by:** Bjorn Helgaas `<bhelgaas@google.com>` (PCI
  maintainer)
- **Reviewed-by:** Manivannan Sadhasivam `<mani@kernel.org>` (MediaTek
  wireless maintainer)
- **Link:**
  https://patch.msgid.link/20260522070646.203115-1-jtornosm@redhat.com
- No Fixes:, Reported-by:, Tested-by:, Cc: stable, or syzbot tags
- Notable: PCI subsystem maintainer sign-off + MediaTek maintainer
  review; references prior MT7922 quirk commit `81f64e925c29`

### Step 1.3: Body analysis
**Record:**
- **Bug:** MT7925 advertises PCIe FLR capability but FLR does not
  correctly reset firmware state
- **Symptom:** After unclean VM termination (crash/force-off), VFIO
  triggers FLR to reset the device before reassignment; firmware init
  fails with patch-semaphore timeouts; device stays broken until
  physical power cycle
- **Normal use unaffected:** Clean VM shutdown/reboot and host-driver
  operation work fine
- **Root cause:** FLR completes from PCI core’s perspective (config
  reads succeed), so no fallback to SBR; firmware state is not properly
  reset
- **Fix:** Set `PCI_DEV_FLAGS_NO_FLR_RESET` via existing `quirk_no_flr`
  for device ID `0x7925`
- **Precedent:** MT7922 (`0x0616`) has the same quirk since commit
  `81f64e925c29` (present in this tree)

### Step 1.4: Hidden bug fix?
**Record:** Not disguised — this is an explicit hardware quirk for
broken FLR. It prevents a real device-stuck failure in VFIO passthrough
scenarios.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **Files:** `drivers/pci/quirks.c` only (+2 lines of code, +1 comment
  line)
- **Functions:** `quirk_no_flr()` (unchanged); new
  `DECLARE_PCI_FIXUP_EARLY` for `PCI_VENDOR_ID_MEDIATEK, 0x7925`
- **Scope:** Single-file surgical hardware-quirk addition

### Step 2.2: Code flow change
**Record:**
- **Before:** MT7925 uses FLR when VFIO/PCI core resets the device; FLR
  appears successful but leaves firmware in a bad state
- **After:** Early boot quirk sets `PCI_DEV_FLAGS_NO_FLR_RESET`;
  `pcie_reset_flr()` / `pci_af_flr()` return `-ENOTTY`;
  `__pci_reset_function_locked()` falls through to bus reset (SBR),
  which works

### Step 2.3: Bug mechanism
**Record:** **Category (h): Hardware workaround / PCI quirk**
- Broken FLR on MT7925 leaves firmware state inconsistent
- Unlike MT7922 (config reads fail after FLR, eventually timing out to
  SBR), MT7925 config reads succeed after FLR, so the reset chain never
  falls back — device remains broken

### Step 2.4: Fix quality
**Record:**
- **Quality:** High — identical pattern to MT7922 and other devices in
  the same `quirk_no_flr` block
- **Regression risk:** Very low — only affects MT7925 reset path; SBR is
  the known-working fallback
- **No unrelated changes**

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:**
- `quirk_no_flr` block and MT7922 entry (`0x0616`) introduced by
  `81f64e925c29` (2025-02-12, Bjorn Helgaas)
- MT7925 quirk line (`0x7925`) is **not** in this tree yet

### Step 3.2: Fixes: tag
**Record:** N/A — no Fixes: tag. Bug is inherent broken hardware FLR
behavior, not a regression from a specific kernel commit.

### Step 3.3: Related file history
**Record:**
- `81f64e925c29` — MT7922 FLR quirk (in tree, was Cc’d stable)
- Recent `quirks.c` changes in 6.18.44 are unrelated PCI quirks (link
  retraining, BW controller, bus-reset avoidance)
- Standalone one-commit fix, not part of a series

### Step 3.4: Author context
**Record:** Jose Ignacio Tornos Martinez (Red Hat); co-signed by PCI
maintainer Bjorn Helgaas. MT7922 quirk was authored by Bjorn Helgaas
with Tested-by from QubesOS developer.

### Step 3.5: Dependencies
**Record:**
- Requires existing `quirk_no_flr` infrastructure — **present** in this
  tree
- Requires MT7925 PCI device support — **present**
  (`drivers/net/wireless/mediatek/mt76/mt7925/pci.c`, device ID
  `0x7925`)
- No prerequisite commits needed; applies standalone

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1–4.5: Lore / b4 dig
**Record:**
- `b4 dig -c <hash>`: **N/A** — commit not in this checkout; no commit
  hash available
- WebFetch/curl to lore.kernel.org and patch.msgid.link: **blocked** by
  Anubis bot protection; could not read thread
- From commit message only: Reviewed-by Manivannan Sadhasivam; Link to
  patch submission
- **UNVERIFIED:** Whether reviewers explicitly nominated for stable in
  the mailing list thread

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `quirk_no_flr()` (early fixup), `pcie_reset_flr()`,
`pci_af_flr()`, `__pci_reset_function_locked()`

### Step 5.2: Callers
**Record:**
- `quirk_no_flr` runs at `DECLARE_PCI_FIXUP_EARLY` during PCI
  enumeration
- `PCI_DEV_FLAGS_NO_FLR_RESET` checked in `pcie_reset_flr()` and
  `pci_af_flr()` (`drivers/pci/pci.c:4357, 4379`)
- `__pci_reset_function_locked()` iterates reset methods; FLR skipped →
  bus reset used (`drivers/pci/pci.c:5008-5067`)
- VFIO calls `__pci_reset_function_locked()` on device release/reset
  (`drivers/vfio/pci/vfio_pci_core.c:707`)

### Step 5.3: Callees
**Record:** Quirk only sets `dev->dev_flags |=
PCI_DEV_FLAGS_NO_FLR_RESET`; reset path uses existing PCI reset
machinery

### Step 5.4: Reachability
**Record:**
- Trigger: VFIO PCI passthrough + unclean VM termination (crash/force-
  off)
- Requires `CONFIG_VFIO_PCI` + `CONFIG_MT7925E` + MT7925 hardware
- Not a general syscall path, but a documented, reproducible VFIO
  workflow

### Step 5.5: Similar patterns
**Record:** MT7922 (`0x0616`), AMD USB/audio controllers, Intel 82579,
SolidRun SNET — all use the same `quirk_no_flr` mechanism in this file

---

## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE

### Step 6.1: Buggy code exists?
**Record:**
- **Local tree:** Linux **6.18.44** (`git describe HEAD` → `v6.18.44`,
  `make kernelversion` → `6.18.44`)
- MT7925 driver present since `c948b5da6bbec` (2023-09-30), ancestor of
  HEAD
- MT7922 FLR quirk present (`0x0616` at `quirks.c:5578`)
- **MT7925 FLR quirk absent** — `0x7925` not in `quirks.c`; commit not
  applied
- Bug is reachable: hardware advertises FLR, kernel will use it without
  this quirk

### Step 6.2: Backport complications
**Record:** **Clean apply expected** — two-line addition to existing
quirk block with no structural changes

### Step 6.3: Related fixes already present?
**Record:** MT7922 quirk (`81f64e925c29`) is in tree; no MT7925-specific
FLR fix present

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem criticality
**Record:** **PCI core quirks** — IMPORTANT for PCI/VFIO virtualization
users with MT7925 hardware

### Step 7.2: Activity
**Record:** `quirks.c` actively maintained; FLR quirks are a well-
established pattern in this subsystem

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who is affected
**Record:** Users of MT7925 PCIe WiFi (`mt7925e`) with VFIO PCI
passthrough — config-specific but real production use (e.g., QubesOS-
style setups)

### Step 8.2: Trigger conditions
**Record:** VFIO-assigned MT7925 + unclean VM shutdown; not every boot,
but reproducible and common in VM crash scenarios; requires privileges
to use VFIO

### Step 8.3: Failure mode severity
**Record:** Device stuck in broken state until **physical power cycle**;
firmware init permanently fails on reassignment. **Severity: HIGH** for
affected users (not kernel oops, but hardware effectively bricked until
reboot/power-cycle)

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** HIGH for VFIO + MT7925 users — restores device
  reusability after unclean VM exit
- **Risk:** VERY LOW — 2-line quirk, proven pattern, PCI maintainer
  authored/reviewed
- **Ratio:** Strongly favors backport

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Real hardware bug with documented failure logs in commit message
- Device unusable until power cycle after VFIO FLR — serious for
  virtualization users
- Trivial 2-line PCI quirk, same pattern as MT7922 (already in this
  tree, was stable-nominated)
- PCI maintainer (Bjorn Helgaas) sign-off; MediaTek maintainer review
- MT7925 driver and PCI device ID `0x7925` both present in 6.18.44
- Classic stable exception: hardware quirk/workaround

**AGAINST backport:**
- Only affects VFIO passthrough path, not normal host-driver operation
- Narrow hardware population (MT7925 PCIe specifically)
- No syzbot/fuzzer report or Cc: stable tag (expected for manual review)

**UNRESOLVED:**
- Mailing list thread content (lore blocked)
- Whether explicit stable nomination appeared in review thread

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — identical to in-tree MT7922
   quirk; maintainer-reviewed
2. Fixes a real bug affecting users? **PASS** — VFIO device stuck after
   unclean VM exit
3. Important issue? **PASS** — hardware effectively bricked until power
   cycle (HIGH for affected users)
4. Small and contained? **PASS** — 2 lines in one file
5. No new features or APIs? **PASS** — PCI quirk only
6. Can apply to local tree? **PASS** — infrastructure and hardware
   support both present

### Step 9.3: Exception category
**Record:** **Hardware quirk/workaround** — explicitly allowed for
stable

### Step 9.4: Decision rationale

For **Linux 6.18.44**, this commit should be backported. The MT7925 PCIe
driver and device ID are in this tree, the `quirk_no_flr` mechanism is
established (including the MT7922 precedent), and without this quirk
VFIO users with MT7925 hardware hit a broken FLR path that leaves the
device unusable until a physical power cycle. The fix is minimal,
follows an existing in-tree pattern, and carries negligible regression
risk.

---

## Verification

- [Phase 1] Parsed commit message: PCI FLR quirk for MT7925; tags: SOB
  (author + Bjorn Helgaas), Reviewed-by Manivannan Sadhasivam, Link to
  patch
- [Phase 2] Diff: +1 comment line, +1
  `DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x7925,
  quirk_no_flr)` in `drivers/pci/quirks.c`
- [Phase 3] `git blame` line 5578: MT7922 quirk from `81f64e925c29`
  (2025-02-12)
- [Phase 3] `git show 81f64e925c29`: MT7922 quirk had Cc:
  stable@vger.kernel.org
- [Phase 3] `git merge-base --is-ancestor 81f64e925c29 HEAD`: MT7922
  quirk is in tree
- [Phase 3] `git merge-base --is-ancestor c948b5da6bbec HEAD`: MT7925
  driver is in tree
- [Phase 3] `c948b5da6bbec` dated 2023-09-30: initial MT7925 driver
- [Phase 4] `b4 dig`: N/A — commit hash not in checkout
- [Phase 4] WebFetch/curl lore.kernel.org: **FAILED** (bot protection)
- [Phase 5] `grep PCI_DEV_FLAGS_NO_FLR_RESET`: used in `pci.c:4357,
  4379`
- [Phase 5] Read `pci_reset_fn_methods`: FLR before bus reset in reset
  chain
- [Phase 5] VFIO calls `__pci_reset_function_locked` at
  `vfio_pci_core.c:707`
- [Phase 6] `git describe HEAD` → `v6.18.44`; `make kernelversion` →
  `6.18.44`
- [Phase 6] `grep 0x7925 drivers/pci/quirks.c`: **NOT FOUND** — quirk
  absent
- [Phase 6] `mt7925/pci.c:14`: `PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK,
  0x7925)` confirmed
- [Phase 6] Read `quirks.c:5558-5586`: `quirk_no_flr` block with MT7922,
  no MT7925
- [Phase 8] Failure mode from commit message: firmware init fails,
  device stuck until power cycle

**YES**

 drivers/pci/quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index f6001be94955e..88d4a3f76bf3b 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5564,6 +5564,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x443, quirk_intel_qat_vf_cap);
  * Intel 82579LM Gigabit Ethernet Controller 0x1502
  * Intel 82579V Gigabit Ethernet Controller 0x1503
  * Mediatek MT7922 802.11ax PCI Express Wireless Network Adapter
+ * Mediatek MT7925 802.11be PCI Express Wireless Network Adapter
  */
 static void quirk_no_flr(struct pci_dev *dev)
 {
@@ -5576,6 +5577,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x7901, quirk_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1502, quirk_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1503, quirk_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x0616, quirk_no_flr);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x7925, quirk_no_flr);
 
 /* FLR may cause the SolidRun SNET DPU (rev 0x1) to hang */
 static void quirk_no_flr_snet(struct pci_dev *dev)
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-6.12] PCI: Avoid FLR for MediaTek MT7925 WiFi

[sashiko-bot]

> From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> 
> [ Upstream commit 9f22b92259bb5ac43e2b9007103787d4418fec56 ]
> 
> The MediaTek MT7925 WiFi device advertises FLR capability, but it does not
> work correctly. This manifests in VFIO passthrough scenarios. Normal VM
> operation works fine, including clean shutdown/reboot. However, when the VM
> terminates uncleanly (crash, force-off), VFIO attempts to reset the device
> before it can be assigned to another VM. Because FLR is broken, the reset
> fails, preventing reuse.
> 
> This is similar to its predecessor MT7922 (see 81f64e925c29 ("PCI: Avoid
> FLR for Mediatek MT7922 WiFi")), but with different symptoms.  The MT7922
> issue manifests as config read failures (returning ~0) after FLR. The
> MT7925 shows different behavior: config reads work correctly after FLR, but
> [ ... ]
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> Link: https://patch.msgid.link/20260522070646.203115-1-jtornosm@redhat.com
> Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

[PATCH AUTOSEL 6.18-5.10] PCI: altera: Protect root bus removal with rescan lock

[Sasha Levin]

From: Hans Zhang <18255117159@163.com>

[ Upstream commit a8759c8ac48c0419f5899e95a6ffc611b07c965b ]

Hold the pci_rescan_remove_lock lock while stopping and removing a root bus
to avoid racing with concurrent rescan or hotplug operations triggered via
sysfs.  Such races may lead to use-after-free issues or system crashes.

Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260521161822.132996-4-18255117159@163.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: PCI: altera: Protect root bus removal with
rescan lock

**Local tree:** `v6.18.44-1-g2736c32da98b9` (kernel 6.18.44)
**Fix commit on mainline:** `a8759c8ac48c0` — **not present in this
tree**
**Buggy code:** present since `ec15c4d0d5d2e` (2019, "PCI: altera: Allow
building as module")

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[PCI: altera]` `[Protect]` — Protect root bus removal with
rescan lock during driver teardown.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Hans Zhang `<18255117159@163.com>` (author)
- **Signed-off-by:** Manivannan Sadhasivam `<mani@kernel.org>` (PCI
  maintainer reviewer)
- **Signed-off-by:** Bjorn Helgaas `<bhelgaas@google.com>` (PCI
  maintainer, committer)
- **Link:**
  `https://patch.msgid.link/20260521161822.132996-4-18255117159@163.com`
- No Fixes:, Reported-by:, Tested-by:, Cc: stable@vger.kernel.org
- Notable: maintainer sign-offs from PCI subsystem; no syzbot or user
  crash report

### Step 1.3: Body analysis
**Record:**
- **Bug:** `altera_pcie_remove()` calls `pci_stop_root_bus()` /
  `pci_remove_root_bus()` without holding `pci_rescan_remove_lock`.
- **Symptom:** Race with concurrent sysfs-triggered PCI rescan or
  hotplug → use-after-free or system crash.
- **Root cause:** Root bus teardown and sysfs rescan/remove paths can
  run concurrently on the same bus topology.
- **Version info:** None explicit; bug dates to 2019 module-support
  commit in this tree.

### Step 1.4: Hidden bug fix?
**Record:** No — this is an explicit synchronization bug fix, not
disguised cleanup.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **File:** `drivers/pci/controller/pcie-altera.c` (+2 lines)
- **Function:** `altera_pcie_remove()`
- **Scope:** Single-file, surgical fix (2 insertions)

### Step 2.2: Code flow change
**Record:**
- **Before:** `pci_stop_root_bus()` → `pci_remove_root_bus()` →
  `altera_pcie_irq_teardown()` with no lock.
- **After:** Same sequence wrapped in `pci_lock_rescan_remove()` /
  `pci_unlock_rescan_remove()`.
- **Path affected:** Platform driver `.remove` callback (module unload /
  device unbind).

### Step 2.3: Bug mechanism
**Record:** **Category: synchronization / race condition.**
- Sysfs rescan (`rescan_store`, `dev_rescan_store` in `pci-sysfs.c`)
  holds `pci_rescan_remove_lock`.
- `altera_pcie_remove()` did not, so teardown and rescan could
  interleave on the same bus.
- `pci_stop_and_remove_bus_device()` uses
  `lockdep_assert_held(&pci_rescan_remove_lock)` — the PCI core expects
  this lock for bus mutation; root-bus removal should follow the same
  rule.

### Step 2.4: Fix quality
**Record:**
- **Quality:** High — matches `pci-aardvark.c`, `pci-mvebu.c`, `pci-
  host-common.c`, `pci-hyperv.c`, `pcie-mediatek-gen3.c`.
- **Regression risk:** Very low — standard mutex, no API change, IRQ
  teardown stays outside the lock (same as other drivers).
- **Red flags:** None.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:**
- Buggy `pci_stop_root_bus`/`pci_remove_root_bus` calls introduced in
  `ec15c4d0d5d2e` (Ley Foon Tan, 2019-04-24).
- Function signature updated in `3a610560aa4fc` (2023) — void remove
  callback; lock omission unchanged.

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

### Step 3.3: Related file history
**Record:**
- Part of 9-patch series `[PATCH 0/9] PCI: controller: Add missing
  rescan lock around root bus removal` (Hans Zhang, May 2026).
- Cover letter: **"Each patch is independent."**
- Merged to mainline as `a8759c8ac48c0` via `7c97ee7c4951a` (Merge
  branch 'pci/controller/rescan_lock').
- Related precedent: `1d59d474e1cb7` "PCI: Hold rescan lock while adding
  devices during host probe" — **present in this tree**; documents a
  real NULL-deref crash from missing rescan lock.

### Step 3.4: Author context
**Record:** Hans Zhang — active PCI contributor (cadence, dwc capability
search, etc.). Patch reviewed/signed by PCI maintainers.

### Step 3.5: Dependencies
**Record:** None.
- `pci_lock_rescan_remove()` exists since `9d16947b75831` (2014) — **in
  this tree**.
- `<linux/pci.h>` already included in `pcie-altera.c`.
- Standalone; applies cleanly to current `pcie-altera.c`.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original discussion
**Record:**
- `b4 dig -c` failed (commit not in HEAD).
- Local mbox/cover: `20260522_18255117159_pci_controller_add_missing_res
  can_lock_around_root_bus_removal.{cover,mbx}`.
- Cover letter explains race with sysfs rescan/hotplug → UAF/crash.
- Triggered by sashiko-bot review of a related cadence patch asking
  whether root bus teardown needs the lock.
- Lore fetch blocked (Anubis bot protection) — discussion content taken
  from local mbox.

### Step 4.2: Reviewers
**Record:** Signed-off-by Manivannan Sadhasivam and Bjorn Helgaas.
Series sent to linux-pci.

### Step 4.3: Bug report
**Record:** No syzbot, bugzilla, or user crash report for Altera
specifically. Cover letter and `1d59d474e1cb7` provide class-of-bug
evidence in PCI core.

### Step 4.4: Series context
**Record:** Patch 3/9; independent per cover letter. Other drivers in
series (cadence, dwc, brcmstb, etc.) have the same bug pattern.

### Step 4.5: Stable list
**Record:** Not searched (lore blocked). No stable nomination found in
local mbox.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `altera_pcie_remove()` only.

### Step 5.2: Callers
**Record:** Called from platform driver framework on:
- `rmmod` (driver is tristate module since 2019)
- platform device unbind
- Module unload is an explicit design goal for post-boot FPGA
  programming.

### Step 5.3: Callees
**Record:** `pci_lock_rescan_remove()`, `pci_stop_root_bus()`,
`pci_remove_root_bus()`, `pci_unlock_rescan_remove()`,
`altera_pcie_irq_teardown()`.

### Step 5.4: Reachability
**Record:**
- Unprivileged users can trigger sysfs PCI rescan
  (`/sys/bus/pci/rescan`, per-device `rescan`).
- Root can unload the module (`rmmod`).
- Concurrent rescan + unload is the race window — realistic on FPGA
  systems that reload bitstreams.
- **Userspace-reachable rescan path:** yes (with appropriate
  privileges).

### Step 5.5: Similar patterns
**Record:** Same missing-lock pattern in cadence, dwc, brcmstb, iproc,
mediatek, rockchip, plda, vmd (series). Already-fixed examples:
aardvark, mvebu, host-common, hyperv, mediatek-gen3.

---

## PHASE 6: CROSS-REFERENCE WITH LOCAL TREE

### Step 6.1: Buggy code present?
**Record:** **Yes.** Current HEAD at lines 1078–1079:

```1073:1081:drivers/pci/controller/pcie-altera.c
static void altera_pcie_remove(struct platform_device *pdev)
{
        struct altera_pcie *pcie = platform_get_drvdata(pdev);
        struct pci_host_bridge *bridge =
pci_host_bridge_from_priv(pcie);

        pci_stop_root_bus(bridge->bus);
        pci_remove_root_bus(bridge->bus);
        altera_pcie_irq_teardown(pcie);
}
```

No `pci_lock_rescan_remove()`. Bug present since v4.19-era module
support.

### Step 6.2: Backport complications
**Record:** **Clean apply** — 2-line addition, no conflicts expected.
`git show a8759c8ac48c0` matches current file context.

### Step 6.3: Related fixes already present?
**Record:** `1d59d474e1cb7` (probe-side rescan lock) is in tree. Altera-
specific remove-path fix (`a8759c8ac48c0`) is **not** in tree.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem criticality
**Record:** **PERIPHERAL** — `CONFIG_PCIE_ALTERA` host controller for
Altera/Intel FPGA (ARM, ARM64, NIOS2). Not universal, but crash/UAF
severity is high when triggered.

### Step 7.2: Activity
**Record:** Moderately active — recent probe leak fix (`09c43b7b7d29c`),
Agilex support, IRQ domain updates.

---

## PHASE 8: IMPACT AND RISK

### Step 8.1: Who is affected
**Record:** Users with `CONFIG_PCIE_ALTERA` on Altera/Intel FPGA PCIe
platforms who unload/reload the driver while PCI sysfs rescan or hotplug
runs.

### Step 8.2: Trigger conditions
**Record:**
- Concurrent `altera_pcie_remove()` and sysfs `rescan` or `remove` on
  the same bus.
- More likely than average because the driver is a module for post-boot
  FPGA loading.
- Requires root for module unload; rescan also typically root.
- **Likelihood:** uncommon but realistic on target hardware.

### Step 8.3: Failure mode severity
**Record:** **HIGH** — UAF and kernel crash (per commit message and PCI
subsystem precedent in `1d59d474e1cb7`).

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** Prevents crash/UAF on supported FPGA platforms during
  driver teardown.
- **Risk:** Very low — 2 lines, established pattern, no behavior change
  beyond serialization.
- **Ratio:** Favorable for backport.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR:**
- Real synchronization bug with documented PCI class-of-crash precedent
- UAF/crash failure mode
- Minimal, obviously correct fix matching multiple peer drivers
- Bug present in this tree since 2019
- No dependencies; clean apply
- Maintainer-reviewed (Helgaas, Sadhasivam)
- Driver explicitly supports module unload scenarios

**AGAINST:**
- No Altera-specific crash report or syzbot hit
- Niche driver (`CONFIG_PCIE_ALTERA`)
- Race needs concurrent unload + rescan

**UNRESOLVED:**
- Lore thread not readable (bot protection); relied on local mbox
- No independent runtime test evidence for Altera specifically

### Step 9.2: Stable rules checklist
| Criterion | Result |
|-----------|--------|
| 1. Obviously correct and tested? | **PASS** — matches established PCI
pattern; maintainer-reviewed |
| 2. Fixes real bug affecting users? | **PASS** — race on module unload
vs sysfs rescan |
| 3. Important issue? | **PASS** — UAF/crash (HIGH severity) |
| 4. Small and contained? | **PASS** — 2 lines, one function |
| 5. No new features/APIs? | **PASS** — synchronization only |
| 6. Can apply to local tree? | **PASS** — clean apply, APIs present |

### Step 9.3: Exception categories
**Record:** None (not device ID, quirk, DT, build, or docs). Standard
race-condition fix.

### Step 9.4: Decision rationale
This is a missing-lock race in root bus teardown — the same class of bug
that caused a documented crash in `1d59d474e1cb7`, already in 6.18.y.
The Altera driver has lacked this protection since module support was
added in 2019. The fix is trivial, follows peer drivers, and prevents
UAF/crash on FPGA platforms where module reload is an intended use case.
Niche scope is offset by high severity and very low backport risk.

---

## Verification

- **[Phase 1]** `git show a8759c8ac48c0`: parsed subject, tags, body
- **[Phase 1]** Local mbox/cover: series context, bot review,
  independent patches
- **[Phase 2]** Diff: +2 lines in `altera_pcie_remove()`
- **[Phase 2]** `drivers/pci/remove.c:143`:
  `lockdep_assert_held(&pci_rescan_remove_lock)` on bus removal helpers
- **[Phase 2]** `drivers/pci/pci-sysfs.c:470,504,539`: sysfs rescan
  holds same lock
- **[Phase 3]** `git blame -L 1073,1081`: bug from `ec15c4d0d5d2e`
  (2019)
- **[Phase 3]** `git show 9d16947b75831`: lock API since 2014
- **[Phase 3]** `git show 1d59d474e1cb7`: related crash from missing
  lock; in tree
- **[Phase 3]** `git log master --grep="Protect root bus removal"`: fix
  `a8759c8ac48c0` on mainline
- **[Phase 3]** `git merge-base --is-ancestor a8759c8ac48c0 HEAD`: fix
  NOT in HEAD
- **[Phase 4]** `b4 dig`: failed; used local mbox instead
- **[Phase 4]** WebFetch lore: blocked by Anubis
- **[Phase 5]** `grep pci_lock_rescan_remove drivers/pci/controller/`:
  peer drivers use same pattern
- **[Phase 5]** `Kconfig`: `PCIE_ALTERA` tristate, ARM/ARM64/NIOS2
- **[Phase 6]** `git describe HEAD`: v6.18.44
- **[Phase 6]** Read `pcie-altera.c:1073-1081`: buggy code confirmed in
  HEAD
- **[Phase 6]** `git show master:.../pcie-altera.c`: fix confirmed on
  mainline
- **[Phase 8]** `ec15c4d0d5d2e` commit message: module support for post-
  boot FPGA load

**YES**The background checks finished and match what we already
concluded:

- **Altera history:** `pcie-altera.c` has never used
  `pci_lock_rescan_remove()`; the missing lock goes back to the 2019
  module-support commit. The lock API itself has been in the tree since
  2014.
- **Mainline status:** The fix landed on `master` via merge
  `7c97ee7c4951a` (`PCI: altera: Protect root bus removal with rescan
  lock`, `a8759c8ac48c0`). It is **not** in your current `v6.18.44`
  checkout.

**Verdict remains YES** for backporting to this 6.18.y tree — small,
obviously correct race fix with crash/UAF potential, and it should apply
cleanly.

 drivers/pci/controller/pcie-altera.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/controller/pcie-altera.c b/drivers/pci/controller/pcie-altera.c
index 76f3823d96139..8ef56e2fabcfb 100644
--- a/drivers/pci/controller/pcie-altera.c
+++ b/drivers/pci/controller/pcie-altera.c
@@ -1075,8 +1075,10 @@ static void altera_pcie_remove(struct platform_device *pdev)
 	struct altera_pcie *pcie = platform_get_drvdata(pdev);
 	struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
 
+	pci_lock_rescan_remove();
 	pci_stop_root_bus(bridge->bus);
 	pci_remove_root_bus(bridge->bus);
+	pci_unlock_rescan_remove();
 	altera_pcie_irq_teardown(pcie);
 }
 
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] PCI: altera: Protect root bus removal with rescan lock

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but missing cleanup of IRQ domain and chained handler in altera_pcie_probe() error paths leads to a resource leak and potential Use-After-Free.
--

commit c2931eaed1e42d3e3d53dfa366745c5d1ac05fe3
Author: Hans Zhang <18255117159@163.com>

PCI: altera: Protect root bus removal with rescan lock

Hold the pci_rescan_remove_lock lock while stopping and removing a root bus
to avoid racing with concurrent rescan or hotplug operations triggered via
sysfs. Such races may lead to use-after-free issues or system crashes.

Link: https://patch.msgid.link/20260521161822.132996-4-18255117159@163.com

> diff --git a/drivers/pci/controller/pcie-altera.c b/drivers/pci/controller/pcie-altera.c
> index 3dbb7adc421c4..7e1db267ae342 100644
> --- a/drivers/pci/controller/pcie-altera.c
> +++ b/drivers/pci/controller/pcie-altera.c
> @@ -1045,8 +1045,10 @@ static void altera_pcie_remove(struct platform_device *pdev)
>  	struct altera_pcie *pcie = platform_get_drvdata(pdev);
>  	struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
>  
> +	pci_lock_rescan_remove();
>  	pci_stop_root_bus(bridge->bus);
>  	pci_remove_root_bus(bridge->bus);
> +	pci_unlock_rescan_remove();
>  	altera_pcie_irq_teardown(pcie);
>  }

[Severity: High]
This isn't a bug introduced by this patch, but does altera_pcie_probe() leak
the IRQ domain and leave a chained IRQ handler pointing to freed memory on
error?

In altera_pcie_probe(), altera_pcie_parse_dt() installs a chained IRQ handler:

drivers/pci/controller/pcie-altera.c:altera_pcie_probe() {
    ...
	ret = altera_pcie_parse_dt(pcie);
	if (ret) {
		dev_err(dev, "Parsing DT failed\n");
		return ret;
	}

	ret = altera_pcie_init_irq_domain(pcie);
	if (ret) {
		dev_err(dev, "Failed creating IRQ Domain\n");
		return ret;
	}
    ...
}

If altera_pcie_init_irq_domain() fails, it returns directly without clearing
the chained IRQ handler.

Similarly, if pci_host_probe() fails at the end of the function:

drivers/pci/controller/pcie-altera.c:altera_pcie_probe() {
    ...
	return pci_host_probe(bridge);
}

The function returns the error directly, which causes devres to free the
pcie structure. However, the chained IRQ handler is still active and will
now point to freed memory, potentially causing a Use-After-Free crash if a
shared interrupt fires. Also, the irq domain allocated in
altera_pcie_init_irq_domain() is leaked.

Should altera_pcie_probe() use goto error paths to call
altera_pcie_irq_teardown() on these failures?

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

[PATCH AUTOSEL 6.18-6.1] PCI: intel-gw: Enable clock before PHY init

[Sasha Levin]

From: Florian Eckert <fe@dev.tdt.de>

[ Upstream commit febf9ed3c35e5eec7ea384ebbd55a5296e3ca5e9 ]

To ensure that the boot sequence is correct, the DWC PCIe core clock must
be switched on before PHY init call [1]. This changes are based on patched
kernel sources of the MaxLinear SDK.

The reason why the MaxLinear SDK is used as a reference here is, that this
PCIe DWC IP is used in the URX851 and URX850 SoC. This SoC was originally
developed by Intel when they acquired Lantiq’s home networking division in
2015 [2]. In 2020 the home network division was sold to MaxLinear [3].
Since then, this SoC belongs to MaxLinear. They use their own SDK, which
runs on kernel version '5.15.x'.

[1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L544
[2] https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home
[3] https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform

Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-4-0a2b933fe04f@dev.tdt.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The background search for `intel,lgm-pcie` in this stable checkout only
turned up merge commits — the tree’s history is too shallow to show the
original introduction. From `v5.15` history, the driver dates to
`ed22aaaede44f` (“PCI: dwc: intel: PCIe RC controller driver”, 2019),
and the wrong clock/PHY ordering has been there since then.

**Verdict for linux-6.18.y: YES** — enable the core clock before
`phy_init()` in `intel_pcie_host_setup()`. It’s a small, vendor-
validated hardware sequencing fix for MaxLinear/Intel Gateway SoCs, and
it applies with a minor tweak (6.18.y still uses inline interrupt enable
instead of `intel_pcie_core_irq_enable()`).

Note: this is patch 4/7 of a larger intel-gw series; full driver
restoration on current dwc may also need the `.start_link()` and ATU
patches from the same series.

 drivers/pci/controller/dwc/pcie-intel-gw.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c b/drivers/pci/controller/dwc/pcie-intel-gw.c
index c21906eced618..8b51eb30112d9 100644
--- a/drivers/pci/controller/dwc/pcie-intel-gw.c
+++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
@@ -285,13 +285,9 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
 
 	intel_pcie_core_rst_assert(pcie);
 	intel_pcie_device_rst_assert(pcie);
-
-	ret = phy_init(pcie->phy);
-	if (ret)
-		return ret;
-
 	intel_pcie_core_rst_deassert(pcie);
 
+	/* Controller clock must be provided earlier than PHY */
 	ret = clk_prepare_enable(pcie->core_clk);
 	if (ret) {
 		dev_err(pcie->pci.dev, "Core clock enable failed: %d\n", ret);
@@ -300,13 +296,17 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
 
 	pci->atu_base = pci->dbi_base + 0xC0000;
 
+	ret = phy_init(pcie->phy);
+	if (ret)
+		goto phy_err;
+
 	intel_pcie_ltssm_disable(pcie);
 	intel_pcie_link_setup(pcie);
 	intel_pcie_init_n_fts(pci);
 
 	ret = dw_pcie_setup_rc(&pci->pp);
 	if (ret)
-		goto app_init_err;
+		goto err;
 
 	dw_pcie_upconfig_setup(pci);
 
@@ -315,7 +315,7 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
 
 	ret = dw_pcie_wait_for_link(pci);
 	if (ret)
-		goto app_init_err;
+		goto err;
 
 	/* Enable integrated interrupts */
 	pcie_app_wr_mask(pcie, PCIE_APP_IRNEN, PCIE_APP_IRN_INT,
@@ -323,11 +323,12 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
 
 	return 0;
 
-app_init_err:
+err:
+	phy_exit(pcie->phy);
+phy_err:
 	clk_disable_unprepare(pcie->core_clk);
 clk_err:
 	intel_pcie_core_rst_assert(pcie);
-	phy_exit(pcie->phy);
 
 	return ret;
 }
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-6.1] PCI: intel-gw: Enable clock before PHY init

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The teardown sequence in `__intel_pcie_remove()` was not updated to match the new initialization order, leading to `phy_exit()` being called while the core clock is disabled.
--

commit f996b74a9755733be971c866c8fb2dd5071a2fa4
Author: Florian Eckert <fe@dev.tdt.de>

PCI: intel-gw: Enable clock before PHY init

This commit reorders the initialization sequence to enable the DWC PCIe
core clock before calling phy_init() to ensure the correct boot sequence.
It also updates the error handling path to symmetrically reverse this
new order.

Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-4-0a2b933fe04f@dev.tdt.de

> diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c b/drivers/pci/controller/dwc/pcie-intel-gw.c
> index c21906eced618..8b51eb30112d9 100644
> --- a/drivers/pci/controller/dwc/pcie-intel-gw.c
> +++ b/drivers/pci/controller/dwc/pcie-intel-gw.c

[ ... ]

> @@ -323,11 +323,12 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
>  
>  	return 0;
>  
> -app_init_err:
> +err:
> +	phy_exit(pcie->phy);
> +phy_err:
>  	clk_disable_unprepare(pcie->core_clk);
>  clk_err:
>  	intel_pcie_core_rst_assert(pcie);
> -	phy_exit(pcie->phy);
>  
>  	return ret;
>  }

[Severity: High]
Since the error handling path was updated to symmetrically reverse the new
initialization order, does the teardown sequence in __intel_pcie_remove()
also need to be updated?

Looking at __intel_pcie_remove():

static void __intel_pcie_remove(struct intel_pcie *pcie)
{
	intel_pcie_core_irq_disable(pcie);
	intel_pcie_turn_off(pcie);
	clk_disable_unprepare(pcie->core_clk);
	intel_pcie_core_rst_assert(pcie);
	phy_exit(pcie->phy);
}

This calls phy_exit() after clk_disable_unprepare() and
intel_pcie_core_rst_assert(), which leaves the PHY being exited without its
required core clock.

Can this sequence lead to unclocked hardware accesses during driver unbind,
potentially triggering an asynchronous external abort or hard bus lockup?

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

[PATCH AUTOSEL 6.18-6.1] PCI/proc: Fix race between pci_proc_init() and pci_bus_add_device()

[Sasha Levin]

From: Krzysztof Wilczyński <kwilczynski@kernel.org>

[ Upstream commit 8857f6578b001bcf5f53c8c6a3936647f05291a8 ]

pci_proc_attach_device() creates procfs entries for PCI devices and is
called from pci_bus_add_device().  It lazily creates the per-bus procfs
directory (bus->procdir) via proc_mkdir() on first use, and returns early
if proc_initialized is not yet set.

On x86 with ACPI, PCI enumeration occurs at subsys_initcall, before
pci_proc_init() sets proc_initialized at device_initcall.  The
for_each_pci_dev() loop in pci_proc_init() then creates procfs entries for
these already-enumerated devices, but runs without holding
pci_rescan_remove_lock.

On ARM64 with devicetree, PCI host bridges probe at device_initcall.  With
async probing enabled, pci_bus_add_device() can run concurrently with
pci_proc_init(), and both may call pci_proc_attach_device() for the same
device or for different devices on the same bus.  As pci_host_probe() holds
pci_rescan_remove_lock while pci_proc_init() does not, there is no
serialisation between the two paths.

When two threads concurrently call pci_proc_attach_device() for devices on
the same bus, both observe bus->procdir as NULL and both call proc_mkdir().
The proc filesystem serialises directory creation internally, so only one
caller succeeds.  The other results in a warning like:

  proc_dir_entry '000c:00/00.0' already registered

The caller receives NULL (duplicate entry) and unconditionally stores it to
bus->procdir, corrupting the valid pointer set by the first caller.

Serialise access to proc_initialized, proc_bus_pci_dir, bus->procdir and
dev->procent with a new mutex local to drivers/pci/proc.c, and store the
created entries to bus->procdir and dev->procent only on success, so a
failed creation can never overwrite a valid pointer.

Additionally, wrap the for_each_pci_dev() loop in pci_proc_init() with
pci_lock_rescan_remove() to serialise against concurrent PCI bus
operations, add an early return in pci_proc_attach_device() when
dev->procent is already set to make the function idempotent, and clear
bus->procdir in pci_proc_detach_bus() to prevent use of a dangling pointer
after proc_remove().

Reported-by: Shuan He <heshuan@bytedance.com>
Closes: https://lore.kernel.org/linux-pci/20250702155112.40124-2-heshuan@bytedance.com/
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20260611150543.511422-1-kwilczynski@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: PCI/proc race fix

**Local tree:** Linux **6.18.44** (`git describe HEAD` →
`v6.18.44-1-g2736c32da98b9`, `make kernelversion` → `6.18.44`)

**Fix status in this tree:** The buggy code is present at HEAD; commit
`3ab0784441504` / upstream `8857f6578b001` is **not** an ancestor of
HEAD.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[PCI/proc]` `[Fix]` — race between `pci_proc_init()` and
`pci_bus_add_device()` during concurrent procfs entry creation.

### Step 1.2: Tags
**Record:**
- **Reported-by:** Shuan He \<heshuan@bytedance.com\> — real-world
  reporter
- **Closes:** https://lore.kernel.org/linux-
  pci/20250702155112.40124-2-heshuan@bytedance.com/ — original bug
  report thread
- **Signed-off-by:** Krzysztof Wilczyński, Bjorn Helgaas (PCI
  maintainer)
- **Link:** https://lore.kernel.org/r/20260611150543.511422-1-
  kwilczynski@kernel.org
- No `Fixes:` tag (expected for manual review)
- No `Cc: stable@vger.kernel.org` (expected)
- Ignore pipeline `Signed-off-by: Sasha Levin`

### Step 1.3: Body analysis
**Record:**
- **Bug:** Concurrent `pci_proc_attach_device()` calls can both see
  `bus->procdir == NULL`, both call `proc_mkdir()`; procfs rejects the
  duplicate with a WARN; the loser stores `NULL` into `bus->procdir`,
  overwriting a valid pointer.
- **Symptom:** `WARN(1, "proc_dir_entry '%s/%s' already registered\n",
  ...)` in dmesg; corrupted `bus->procdir`; missing/broken
  `/proc/bus/pci` entries.
- **Trigger (ARM64 DT):** PCI host bridges probe at `device_initcall`;
  with async probing, `pci_bus_add_device()` can run concurrently with
  `pci_proc_init()`; `pci_host_probe()` holds `pci_rescan_remove_lock`
  but `pci_proc_init()` did not.
- **Trigger (x86 ACPI):** Enumeration at `subsys_initcall` before proc
  init; `pci_proc_init()`'s `for_each_pci_dev()` loop lacked
  `pci_rescan_remove_lock`.
- **Root cause:** No serialization around lazy `bus->procdir` /
  `dev->procent` creation; unconditional assignment of failed
  `proc_mkdir()` result.

### Step 1.4: Hidden bug fix?
**Record:** No — explicitly described as a race/pointer-corruption bug
fix, not disguised cleanup.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **File:** `drivers/pci/proc.c` only (+56 / -23 lines)
- **Functions modified/added:** `__pci_proc_attach_bus()` (new),
  `pci_proc_attach_device()`, `pci_proc_detach_device()`,
  `pci_proc_detach_bus()`, `pci_proc_init()`
- **Scope:** Single-file surgical fix

### Step 2.2: Code flow changes
**Record:**
- **Hunk 1:** Add `pci_proc_lock` mutex.
- **Hunk 2:** Extract `__pci_proc_attach_bus()` — create bus proc dir in
  temp variable, assign to `bus->procdir` only on success; skip if
  already set.
- **Hunk 3:** `pci_proc_attach_device()` — take `pci_proc_lock`; early-
  return if `dev->procent` already set (idempotent); call
  `__pci_proc_attach_bus()`; assign `dev->procent` only on successful
  `proc_create_data()`.
- **Hunk 4:** `pci_proc_detach_device()` / `pci_proc_detach_bus()` —
  serialize under same mutex; clear `bus->procdir = NULL` after
  `proc_remove()`.
- **Hunk 5:** `pci_proc_init()` — init under `scoped_guard(mutex,
  &pci_proc_lock)`; wrap `for_each_pci_dev()` loop with
  `pci_lock_rescan_remove()` / `pci_unlock_rescan_remove()`.

### Step 2.3: Bug mechanism
**Record:** **Category:** Race condition + pointer corruption
(reference/state bug).
- **Before:** Two threads could race on `bus->procdir`; loser's
  `proc_mkdir()` returned NULL (duplicate), stored unconditionally →
  valid pointer overwritten with NULL.
- **After:** Mutex serializes all proc attach/detach/init; pointer
  assigned only after successful creation; idempotent early returns
  prevent duplicate work.

Verified in `fs/proc/generic.c:403-416`: `proc_register()` returns NULL
on duplicate with `WARN(1, "proc_dir_entry '%s/%s' already
registered\n", ...)`.

### Step 2.4: Fix quality
**Record:** Fix is minimal, obviously correct, and follows existing PCI
patterns (`pci_lock_rescan_remove()`, `guard(mutex)` used elsewhere in
PCI). Low regression risk — adds a local mutex and tightens assignment
logic. `lockdep_assert_held()` documents locking expectations.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** Lazy `bus->procdir = proc_mkdir(...)` pattern dates to
initial import (`1da177e4c3f41`, Linux 2.6.12-rc2). Race window widened
when `pci_proc_attach_device()` moved back to `pci_bus_add_device()` in
`ef37702eb3cae` (2013). Bug has been latent for years; practical trigger
on ARM64+async probe is newer.

### Step 3.2: Fixes: tag
**Record:** N/A — no `Fixes:` tag in commit message.

### Step 3.3: Related file history
**Record:** Recent `drivers/pci/proc.c` changes are unrelated cleanups
(mmap, PDE_DATA removal). No duplicate fix in this tree. Fix commit
`3ab0784441504` exists on `autosel` branch but not in current HEAD.

### Step 3.4: Author context
**Record:** Krzysztof Wilczyński is an active PCI contributor/maintainer
(multiple PCI commits in this tree). Bjorn Helgaas committed the fix
upstream.

### Step 3.5: Dependencies
**Record:** Standalone — no series prerequisites.
- `guard(mutex)` / `scoped_guard` available via `#include
  <linux/module.h>` → `cleanup.h` (proc.c already includes module.h).
- `pci_lock_rescan_remove()` exists in `drivers/pci/probe.c` and is
  declared in `drivers/pci/pci.h`.
- Patch applies cleanly against current `drivers/pci/proc.c` at HEAD.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original discussion
**Record:**
- **b4 dig -c 3ab0784441504:** https://patch.msgid.link/20260611150543.5
  11422-1-kwilczynski@kernel.org
- **Series revisions:** v1 (2026-04-30) → v2/v3 (2026-06-06) → v4
  (2026-06-11, committed version)
- Lore direct fetch blocked by bot protection; thread retrieved via `b4
  dig -m`.

### Step 4.2: Reviewers
**Record:** **b4 dig -w** CC'd: Bjorn Helgaas, Manivannan Sadhasivam,
Lorenzo Pieralisi, Ilpo Järvinen, Lukas Wunner, Shuan He (reporter),
linux-pci@vger.kernel.org — appropriate PCI maintainer coverage.

### Step 4.3: Bug report
**Record:** Reported-by Shuan He (Bytedance). Closes July 2025 lore
thread. WebFetch to lore blocked; bug mechanism and reporter confirmed
from commit message and mbox metadata.

### Step 4.4: Related patches
**Record:** Standalone v4 patch; no multi-patch series dependency.

### Step 4.5: Stable list history
**Record:** No stable-list discussion found in retrieved mbox thread
(UNVERIFIED for broader stable@ search due to lore access limits).

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `pci_proc_attach_device()`, `pci_proc_detach_device()`,
`pci_proc_detach_bus()`, `pci_proc_init()`, `__pci_proc_attach_bus()`.

### Step 5.2: Callers
**Record:**
- `pci_proc_attach_device()` called from `pci_bus_add_device()`
  (`drivers/pci/bus.c:358`) — normal device bring-up path.
- `pci_proc_init()` called via `device_initcall` at boot.
- Detach called from `drivers/pci/remove.c` on device/bus removal.
- `pci_bus_add_device()` reached from `pci_host_probe()` →
  `pci_bus_add_devices()` (`probe.c:3318-3320`, under
  `pci_lock_rescan_remove()`).

### Step 5.3: Callees
**Record:** `proc_mkdir()`, `proc_create_data()`, `proc_remove()`,
`proc_set_size()`, `pci_lock_rescan_remove()` /
`pci_unlock_rescan_remove()`.

### Step 5.4: Reachability
**Record:** Boot-time path on ARM64 DT systems with async device probing
— common production configuration. Also reachable during PCI
hotplug/rescan via `pci_bus_add_device()`. Requires `CONFIG_PROC_FS`
(proc.c is wrapped in `#ifdef CONFIG_PROC_FS` in `pci.h`).

### Step 5.5: Similar patterns
**Record:** No other lazy proc-dir creation races found in PCI code;
this is the sole attach point for PCI proc entries.

**Corruption consequence (verified):** If thread A sets `bus->procdir`
valid and thread B overwrites with NULL before A reads `bus->procdir`
for `proc_create_data()`, A passes NULL parent (`proc.c:441-442` at
HEAD). `proc_create_data()` passes parent to `proc_register()` without
NULL guard — potential oops during boot enumeration.

---

## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE

### Step 6.1: Buggy code exists?
**Record:** **YES.** At HEAD, `drivers/pci/proc.c:428-437` still has
unconditional `bus->procdir = proc_mkdir(...)` without locking.
`pci_proc_init()` at lines 464-472 lacks `pci_rescan_remove_lock`.
`pci_proc_detach_bus()` does not clear `bus->procdir`.

### Step 6.2: Backport complications
**Record:** **Clean apply expected.** File structure matches the patch
base. No conflicting recent changes to proc attach logic.
`guard()`/`scoped_guard()` infrastructure present in 6.18.

### Step 6.3: Related fixes already present?
**Record:** **None.** `git merge-base --is-ancestor 3ab0784441504 HEAD`
→ fix NOT in HEAD. `git merge-base --is-ancestor 8857f6578b001 HEAD` →
upstream fix NOT in HEAD.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem criticality
**Record:** **drivers/pci** — IMPORTANT subsystem. Affects PCI
enumeration/procfs on all platforms with `CONFIG_PCI` +
`CONFIG_PROC_FS`.

### Step 7.2: Activity
**Record:** PCI subsystem actively maintained in 6.18; this is a
targeted fix to long-standing init-race code, not dead code.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who is affected
**Record:** ARM64 (and other DT) systems with PCI host controllers
probing at `device_initcall` and async probing enabled. Also any
platform where `pci_proc_init()` races with concurrent
`pci_bus_add_device()`. x86 less likely at boot but hotplug paths remain
relevant.

### Step 8.2: Trigger conditions
**Record:** Concurrent threads calling `pci_proc_attach_device()` for
devices on the same bus during boot init. Timing-dependent but realistic
with async probe. Unprivileged users cannot trigger at boot; hotplug
paths may be root-controlled.

### Step 8.3: Failure mode severity
**Record:**
- Kernel WARN during boot (verified procfs path)
- `bus->procdir` pointer corruption
- Missing `/proc/bus/pci/<bus>/<dev>` entries (tools relying on legacy
  PCI proc interface break)
- Potential NULL-parent `proc_create_data()` if corruption races with
  in-flight attach
- **Severity: HIGH** (pointer corruption + plausible crash during init)

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** HIGH — prevents boot-time race, pointer corruption, and
  broken PCI procfs on affected platforms
- **Risk:** LOW — single-file mutex addition, well-reviewed, no API
  changes
- **Ratio:** Strong benefit, minimal risk

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Real, reported race with concrete dmesg symptom
- Pointer corruption of `bus->procdir` (kernel data structure
  corruption)
- Plausible crash path via NULL `bus->procdir` in `proc_create_data()`
- Small, single-file fix reviewed by PCI maintainer (Bjorn Helgaas)
- Buggy code confirmed present in Linux 6.18.44 tree
- v4 patch after 4 review iterations

**AGAINST backport:**
- Requires `CONFIG_PROC_FS` (most distro kernels have it)
- Timing-dependent race (but realistic on ARM64+async probe)
- Legacy `/proc/bus/pci` interface (less critical than sysfs) —
  mitigated by corruption severity

**Unresolved:** Full text of original Bytedance bug report (lore bot-
blocked); no explicit stable@ nomination found in thread.

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — mutex serialization +
   assign-on-success; reviewed by maintainer; reporter confirmed issue
2. Fixes a real bug affecting users? **PASS** — Bytedance report, ARM64
   DT boot path
3. Important issue? **PASS** — pointer corruption, WARN, possible init
   crash, broken procfs
4. Small and contained? **PASS** — 1 file, ~80 lines total
5. No new features/APIs? **PASS** — synchronization only
6. Can apply to local tree? **PASS** — code present, dependencies
   satisfied, clean apply expected

### Step 9.3: Exception categories
**Record:** None (not device ID, quirk, DT, build, or docs) — standard
bug-fix backport.

### Step 9.4: Decision rationale
This fix addresses a genuine initialization race in PCI procfs setup
that corrupts `bus->procdir` on a realistic ARM64+async-probe boot path.
The buggy code is present in this 6.18.44 tree, the fix is small and
self-contained, and the failure mode (pointer corruption, WARN, missing
proc entries, possible NULL deref) meets stable importance thresholds.

---

## Verification

- [Phase 1] Parsed subject, tags (Reported-by, Closes, Link, SOBs);
  ignored pipeline SOB
- [Phase 1] Identified explicit race/pointer-corruption bug from commit
  message
- [Phase 2] Read full diff from `git show 3ab0784441504`; confirmed 1
  file, +56/-23
- [Phase 2] Verified `proc_register()` duplicate behavior at
  `fs/proc/generic.c:403-416`
- [Phase 2] Verified current HEAD code at `drivers/pci/proc.c:419-476`
  lacks fix
- [Phase 3] `git blame -L 428,437`: lazy procdir pattern since 2.6.12
- [Phase 3] `git show ef37702eb3cae`: `pci_proc_attach_device` moved to
  `pci_bus_add_device()` in 2013
- [Phase 3] `git merge-base --is-ancestor 3ab0784441504 HEAD` → NOT in
  HEAD
- [Phase 3] `git merge-base --is-ancestor 8857f6578b001 HEAD` → upstream
  NOT in HEAD
- [Phase 4] `b4 dig -c 3ab0784441504` → lore URL found
- [Phase 4] `b4 dig -a` → v1–v4 series, v4 is committed version
- [Phase 4] `b4 dig -w` → PCI maintainers CC'd
- [Phase 4] `b4 dig -m /tmp/pci_proc_race.mbox` → thread saved
- [Phase 4] WebFetch lore URLs → blocked by bot protection (UNVERIFIED
  for inline thread text)
- [Phase 5] `grep pci_proc_attach_device` → caller
  `pci_bus_add_device()` at `bus.c:358`
- [Phase 5] `grep pci_host_probe` → `pci_lock_rescan_remove()` around
  `pci_bus_add_devices()` at `probe.c:3318-3320`
- [Phase 5] Verified `proc_create_data()` uses parent without NULL check
  (`generic.c:587-597`)
- [Phase 6] `git describe HEAD` → v6.18.44; `make kernelversion` →
  6.18.44
- [Phase 6] Confirmed buggy code present, fix absent at HEAD
- [Phase 6] Verified `guard(mutex)` available via `module.h` →
  `cleanup.h` include chain
- [Phase 6] Verified `pci_lock_rescan_remove()` exists and is used in
  PCI core
- [Phase 7] PCI subsystem classified IMPORTANT
- [Phase 8] Assessed severity HIGH based on pointer corruption +
  verified procfs/proc_create paths

**YES**The background git searches finished successfully.

They confirmed the fix exists as commit `3ab0784441504` (upstream
`8857f6578b001`) on the `autosel` branch, but it is **not** in your
current 6.18.44 HEAD — the race in `drivers/pci/proc.c` is still present
there.

**Verdict from the analysis: YES** — this should be backported to this
tree. It is a small, reviewed fix for a real boot-time race that can
corrupt `bus->procdir` on ARM64 systems with async probing.

 drivers/pci/proc.c | 79 ++++++++++++++++++++++++++++++++--------------
 1 file changed, 56 insertions(+), 23 deletions(-)

diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index 9348a0fb80847..34fbacbafe919 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -18,6 +18,7 @@
 #include "pci.h"
 
 static int proc_initialized;	/* = 0 */
+static DEFINE_MUTEX(pci_proc_lock);
 
 static loff_t proc_bus_pci_lseek(struct file *file, loff_t off, int whence)
 {
@@ -416,40 +417,64 @@ static const struct seq_operations proc_bus_pci_devices_op = {
 
 static struct proc_dir_entry *proc_bus_pci_dir;
 
-int pci_proc_attach_device(struct pci_dev *dev)
+static int __pci_proc_attach_bus(struct pci_bus *bus)
 {
-	struct pci_bus *bus = dev->bus;
-	struct proc_dir_entry *e;
+	struct proc_dir_entry *dir;
 	char name[16];
 
+	lockdep_assert_held(&pci_proc_lock);
+
 	if (!proc_initialized)
 		return -EACCES;
 
-	if (!bus->procdir) {
-		if (pci_proc_domain(bus)) {
-			sprintf(name, "%04x:%02x", pci_domain_nr(bus),
-					bus->number);
-		} else {
-			sprintf(name, "%02x", bus->number);
-		}
-		bus->procdir = proc_mkdir(name, proc_bus_pci_dir);
-		if (!bus->procdir)
-			return -ENOMEM;
-	}
+	if (bus->procdir)
+		return 0;
+
+	if (pci_proc_domain(bus))
+		sprintf(name, "%04x:%02x", pci_domain_nr(bus), bus->number);
+	else
+		sprintf(name, "%02x", bus->number);
+
+	dir = proc_mkdir(name, proc_bus_pci_dir);
+	if (!dir)
+		return -ENOMEM;
+
+	bus->procdir = dir;
+
+	return 0;
+}
+
+int pci_proc_attach_device(struct pci_dev *dev)
+{
+	struct pci_bus *bus = dev->bus;
+	struct proc_dir_entry *entry;
+	char name[16];
+	int ret;
+
+	guard(mutex)(&pci_proc_lock);
+
+	if (dev->procent)
+		return 0;
+
+	ret = __pci_proc_attach_bus(bus);
+	if (ret)
+		return ret;
 
 	sprintf(name, "%02x.%x", PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
-	e = proc_create_data(name, S_IFREG | S_IRUGO | S_IWUSR, bus->procdir,
-			     &proc_bus_pci_ops, dev);
-	if (!e)
+	entry = proc_create_data(name, S_IFREG | S_IRUGO | S_IWUSR,
+				 bus->procdir, &proc_bus_pci_ops, dev);
+	if (!entry)
 		return -ENOMEM;
-	proc_set_size(e, dev->cfg_size);
-	dev->procent = e;
+
+	proc_set_size(entry, dev->cfg_size);
+	dev->procent = entry;
 
 	return 0;
 }
 
 int pci_proc_detach_device(struct pci_dev *dev)
 {
+	guard(mutex)(&pci_proc_lock);
 	proc_remove(dev->procent);
 	dev->procent = NULL;
 	return 0;
@@ -457,19 +482,27 @@ int pci_proc_detach_device(struct pci_dev *dev)
 
 int pci_proc_detach_bus(struct pci_bus *bus)
 {
+	guard(mutex)(&pci_proc_lock);
 	proc_remove(bus->procdir);
+	bus->procdir = NULL;
 	return 0;
 }
 
 static int __init pci_proc_init(void)
 {
 	struct pci_dev *dev = NULL;
-	proc_bus_pci_dir = proc_mkdir("bus/pci", NULL);
-	proc_create_seq("devices", 0, proc_bus_pci_dir,
-		    &proc_bus_pci_devices_op);
-	proc_initialized = 1;
+
+	scoped_guard(mutex, &pci_proc_lock) {
+		proc_bus_pci_dir = proc_mkdir("bus/pci", NULL);
+		proc_create_seq("devices", 0, proc_bus_pci_dir,
+				&proc_bus_pci_devices_op);
+		proc_initialized = 1;
+	}
+
+	pci_lock_rescan_remove();
 	for_each_pci_dev(dev)
 		pci_proc_attach_device(dev);
+	pci_unlock_rescan_remove();
 
 	return 0;
 }
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-6.1] PCI/proc: Fix race between pci_proc_init() and pci_bus_add_device()

[sashiko-bot]

> From: Krzysztof Wilczyński <kwilczynski@kernel.org>
> 
> [ Upstream commit 8857f6578b001bcf5f53c8c6a3936647f05291a8 ]
> 
> pci_proc_attach_device() creates procfs entries for PCI devices and is
> called from pci_bus_add_device().  It lazily creates the per-bus procfs
> directory (bus->procdir) via proc_mkdir() on first use, and returns early
> if proc_initialized is not yet set.
> 
> On x86 with ACPI, PCI enumeration occurs at subsys_initcall, before
> pci_proc_init() sets proc_initialized at device_initcall.  The
> for_each_pci_dev() loop in pci_proc_init() then creates procfs entries for
> these already-enumerated devices, but runs without holding
> pci_rescan_remove_lock.
> 
> [ ... ]
> Closes: https://lore.kernel.org/linux-pci/20250702155112.40124-2-heshuan@bytedance.com/
> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Link: https://lore.kernel.org/r/20260611150543.511422-1-kwilczynski@kernel.org
> Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

[PATCH AUTOSEL 6.18-5.10] PCI: rockchip: Protect root bus removal with rescan lock

[Sasha Levin]

From: Hans Zhang <18255117159@163.com>

[ Upstream commit 0bd9611587bb494c33566d825fe34b2705e4b167 ]

Hold the pci_rescan_remove_lock lock while stopping and removing a root bus
to avoid racing with concurrent rescan or hotplug operations triggered via
sysfs.  Such races may lead to use-after-free issues or system crashes.

Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260521161822.132996-8-18255117159@163.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

### Step 1.1: Parse the Subject Line
**Record:** `[PCI: rockchip] [Protect] Protect root bus removal with
rescan lock` — subsystem is Rockchip PCIe host controller; action is
synchronization/protection (bug fix).

### Step 1.2: Parse All Commit Message Tags
**Record:**
- **Fixes:** none
- **Reported-by:** none
- **Tested-by:** none
- **Reviewed-by:** none
- **Acked-by:** none
- **Link:**
  `https://patch.msgid.link/20260521161822.132996-8-18255117159@163.com`
- **Cc: stable:** none
- **Signed-off-by:** Hans Zhang, Manivannan Sadhasivam, Bjorn Helgaas
  (ignore pipeline-added SOBs per instructions)

Notable: Signed-off-by from PCI maintainer Bjorn Helgaas. No syzbot or
user bug reports.

### Step 1.3: Analyze Commit Body
**Record:**
- **Bug:** `rockchip_pcie_remove()` tears down the root bus without
  holding the global PCI rescan/remove mutex, allowing concurrent sysfs-
  driven rescan or hotplug to operate on the same bus hierarchy.
- **Symptom:** Use-after-free or system crash.
- **Root cause:** Missing `pci_lock_rescan_remove()` /
  `pci_unlock_rescan_remove()` around `pci_stop_root_bus()` +
  `pci_remove_root_bus()`.
- **Version info:** None in commit message.

### Step 1.4: Detect Hidden Bug Fixes
**Record:** Not disguised — explicitly a race-condition / crash fix, not
cleanup or optimization.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory the Changes
**Record:**
- **Files:** `drivers/pci/controller/pcie-rockchip-host.c` (+2 lines)
- **Functions:** `rockchip_pcie_remove()`
- **Scope:** Single-file, surgical fix (2 lines added)

### Step 2.2: Code Flow Change
**Record:**
- **Hunk (remove path):** Before — `pci_stop_root_bus()` and
  `pci_remove_root_bus()` run unlocked. After — same calls wrapped in
  `pci_lock_rescan_remove()` / `pci_unlock_rescan_remove()`. Affects
  driver remove / module-unbind path only.

### Step 2.3: Identify Bug Mechanism
**Record:** **Category:** Synchronization / race condition.
**Mechanism:** Concurrent sysfs PCI rescan (`/sys/bus/pci/rescan`, per-
device `rescan`, `remove`) or hotplug can walk/modify the bus device
list while `rockchip_pcie_remove()` is tearing it down without the
global mutex that sysfs paths already hold.

### Step 2.4: Assess Fix Quality
**Record:** Obviously correct — matches the established pattern in
`pci_host_common_remove()`, `mtk_pcie_remove()`, `mvebu` and `aardvark`
remove paths. Minimal, no API changes. **Regression risk:** Very low;
mutex is the same one used everywhere else for this purpose.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame Changed Lines
**Record:** `pci_stop_root_bus()` / `pci_remove_root_bus()` in
`rockchip_pcie_remove()` introduced by Rob Herring (2020-05-22, commit
`f473182c7524dd`). Remove function itself dates to Shawn Lin
(2018-05-09). Driver added 2016 (`e77f847df54c6`). Bug has been present
since the stop/remove calls were added without locking.

### Step 3.2: Follow Fixes: Tag
**Record:** No `Fixes:` tag present — N/A.

### Step 3.3: File History for Related Changes
**Record:** Part of a 9-patch series "[PATCH 0/9] PCI: controller: Add
missing rescan lock around root bus removal" (local mbox). Each patch is
independent per cover letter. `pci_lock_rescan_remove()` infrastructure
added in 2014 (`9d16947b75831`). `pci_host_common_remove()` has used the
lock since 2018 (`01fcb7f777a9f`). Fix is **not** yet merged in this
tree (grep shows no lock in rockchip remove; `git log --grep` for
subject returned empty).

### Step 3.4: Author's Other Commits
**Record:** Hans Zhang is an active PCI contributor (cadence, dwc
capability-search series, etc.). Not the Rockchip driver author; fixing
a cross-driver synchronization gap.

### Step 3.5: Prerequisites
**Record:** No dependencies. `pci_lock_rescan_remove()` /
`pci_unlock_rescan_remove()` exist in this tree (since 2014). Driver
includes `../pci.h` → `<linux/pci.h>`, so no new includes needed.
Standalone, applies cleanly.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Patch Discussion
**Record:** `b4 dig` could not be run on an unmerged commit hash. Used
local mbox `20260522_18255117159_pci_controller_add_missing_rescan_lock_
around_root_bus_removal.mbx`. Cover letter explains race with sysfs
rescan/hotplug → UAF/crash. References sashiko-bot review flagging the
same pattern in cadence code. **No review replies** in the mbox (patches
only). WebFetch of lore URL blocked by bot protection.

### Step 4.2: Reviewers
**Record:** Cover letter only; no Reviewed-by/Acked-by in thread. Commit
has SOB from Manivannan Sadhasivam and Bjorn Helgaas (PCI maintainer).

### Step 4.3: Bug Report
**Record:** No external bug report, syzbot, or KASAN trace. Issue
identified by code review / bot review of the pattern.

### Step 4.4: Related Patches
**Record:** 9-patch series for cadence, dwc, altera, brcmstb, iproc,
mediatek, rockchip, vmd, plda. Each independent. Rockchip is patch 7/9.

### Step 4.5: Stable Mailing List
**Record:** No stable-list discussion found in available sources.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** `rockchip_pcie_remove()` — only function modified.

### Step 5.2: Trace Callers
**Record:** Called via `.remove = rockchip_pcie_remove` in
`rockchip_pcie_driver`, registered with `module_platform_driver()`.
Triggers on platform device removal: module unload (`rmmod` if built as
module), driver unbind, or platform teardown.

### Step 5.3: Trace Callees
**Record:** `pci_lock_rescan_remove()`, `pci_stop_root_bus()`,
`pci_remove_root_bus()`, `pci_unlock_rescan_remove()`, then
`irq_domain_remove()`, clock/regulator cleanup.

### Step 5.4: Call Chain / Reachability
**Record:** Race is between `rockchip_pcie_remove()` and sysfs paths in
`pci-sysfs.c` (`rescan_store`, `dev_rescan_store`, `remove_store`,
`bus_rescan_store`) — all hold `pci_lock_rescan_remove()`. An admin
writing to `/sys/bus/pci/rescan` (or per-bus/device rescan/remove) while
the driver is being removed can hit the race. Reachable on any Rockchip
system with `CONFIG_PCIE_ROCKCHIP_HOST`.

### Step 5.5: Similar Patterns
**Record:** Controllers **with** lock: `pci-host-common.c`, `pcie-
mediatek-gen3.c`, `pci-mvebu.c`, `pci-aardvark.c`, `pci-hyperv.c`.
Controllers **without** lock (same bug class): rockchip, cadence, dwc,
altera, brcmstb, iproc, mediatek (non-gen3), vmd, plda, tegra, etc.
Rockchip is a clear oversight relative to the common pattern.

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Does Buggy Code Exist?
**Record:** **Yes.** Tree is **v6.18.44** (`git describe HEAD` →
`v6.18.44-1-g2736c32da98b9`, `make kernelversion` → `6.18.44`).
`rockchip_pcie_remove()` at lines 1015–1016 calls `pci_stop_root_bus()`
/ `pci_remove_root_bus()` **without** the lock. Driver present since
v4.8 era; bug since ~2020.

### Step 6.2: Backport Complications
**Record:** **Clean apply** — 2-line addition, no structural changes, no
conflicts expected.

### Step 6.3: Related Fixes Already Present?
**Record:** No equivalent fix in this tree. `git log --grep="Protect
root bus removal"` returned empty. Mediatek-gen3, mvebu, aardvark, pci-
host-common already have the lock; rockchip does not.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem Criticality
**Record:** **drivers/pci/controller** — IMPORTANT. PCI core affects
device enumeration and all downstream PCI devices on Rockchip SoCs
(RK3399, RK3568, etc.).

### Step 7.2: Subsystem Activity
**Record:** Actively maintained; recent rockchip commits in this tree
(link speed, error logging, reset timing).

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Users of Rockchip SoCs with `CONFIG_PCIE_ROCKCHIP_HOST`
(depends on `ARCH_ROCKCHIP`). Embedded/ARM boards using the legacy
Rockchip AXI PCIe host controller.

### Step 8.2: Trigger Conditions
**Record:** Driver remove/unbind concurrent with PCI sysfs rescan or
remove (typically root). Uncommon in steady state but realistic during
module reload, driver unbind testing, or admin sysfs operations.
Requires privileges for sysfs writes; remove path can be triggered by
module unload or device unbind.

### Step 8.3: Failure Mode Severity
**Record:** UAF / kernel crash — **HIGH** (potential **CRITICAL**
depending on exploitability of the freed PCI structures).

### Step 8.4: Risk-Benefit
**Record:** **Benefit:** HIGH — prevents real crashes on a long-standing
code path. **Risk:** VERY LOW — 2-line addition using existing, well-
tested API, matching multiple peer drivers. **Ratio:** Strongly favors
backport.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Real synchronization bug with documented crash/UAF consequence
- Matches PCI core documentation: rescan/remove must run under
  `pci_rescan_remove_lock` (comment in `probe.c` lines 3536–3538)
- Peer drivers already use this pattern; rockchip is an outlier
- 2-line, obviously correct fix
- Buggy code confirmed present in v6.18.44 tree
- Driver has been in production kernels for years
- Signed-off-by PCI maintainer

**AGAINST backport:**
- No user-reported crash or syzbot reproducer (theoretical/code-review
  finding)
- Part of a 9-patch series (but each patch is independent)

**Unresolved:** No runtime crash report; lore thread review discussion
unavailable (bot-blocked).

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — pattern proven across
   multiple drivers; no Tested-by but change is trivial.
2. Fixes a real bug? **PASS** — missing mutex on a documented-required
   code path.
3. Important issue? **PASS** — UAF/system crash.
4. Small and contained? **PASS** — 2 lines, one function.
5. No new features/APIs? **PASS** — synchronization only.
6. Can apply to local tree? **PASS** — APIs and buggy code both present.

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

### Step 9.4: Decision Rationale

This commit closes a long-standing race in `rockchip_pcie_remove()`
where root bus teardown was not serialized against sysfs PCI
rescan/remove operations. The PCI core has required this mutex since
2014, and the generic host-common remove path has used it since 2018.
Rockchip was simply missed. The fix is minimal, follows established
convention, and prevents crashes on Rockchip platforms during driver
removal concurrent with PCI sysfs operations. For the v6.18.44 tree
being evaluated, the buggy code is present and the fix applies cleanly.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body; no Fixes:/Reported-by/syzbot
- **[Phase 2]** Diff: +2 lines in `rockchip_pcie_remove()` wrapping
  stop/remove with lock
- **[Phase 3]** `git describe HEAD` → v6.18.44; `git blame` →
  stop/remove added f473182c (2020); driver since e77f847df54c6 (2016)
- **[Phase 3]** `git show 9d16947b75831` → lock API added 2014; `git
  blame pci-host-common.c` → lock in remove since 01fcb7f777a9f (2018)
- **[Phase 3]** `git log --grep="Protect root bus removal"` → empty (not
  merged)
- **[Phase 4]** Read local mbox cover + patch 7/9; 9 independent
  patches; sashiko-bot race comment verified
- **[Phase 4]** WebFetch lore URL → blocked; b4 dig on unmerged commit →
  N/A
- **[Phase 5]** `grep pci_lock_rescan_remove drivers/pci/controller/` →
  rockchip absent; mvebu/aardvark/mediatek-gen3/hyperv present
- **[Phase 5]** Read `pci-sysfs.c` rescan/remove stores — all hold lock
- **[Phase 5]** Read `probe.c:3536-3552` — documents lock requirement
- **[Phase 6]** Read `rockchip_pcie_remove()` lines 1009–1016 — buggy
  code confirmed in tree
- **[Phase 6]** `Kconfig` → `PCIE_ROCKCHIP_HOST` tristate,
  `ARCH_ROCKCHIP`
- **[Phase 8]** Race between remove and sysfs rescan → UAF/crash per
  commit message and PCI core design

**YES**The background checks finished and match what the analysis
already assumed:

- **Search for commit in tree:** `b4 dig` on HEAD didn’t match this
  patch; `git log --grep` for the subject also found nothing. The fix
  isn’t in this tree yet.
- **Check if fix already merged:** `git log --grep="rockchip.*rescan
  lock"` and `--grep="Protect root bus removal"` both returned empty —
  confirmed not merged in v6.18.44.

**Verdict stands: YES** — backport the 2-line `pci_lock_rescan_remove()`
wrap in `rockchip_pcie_remove()` to close the sysfs rescan/remove race.

 drivers/pci/controller/pcie-rockchip-host.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
index ee1822ca01db3..d203c4876d304 100644
--- a/drivers/pci/controller/pcie-rockchip-host.c
+++ b/drivers/pci/controller/pcie-rockchip-host.c
@@ -1012,8 +1012,10 @@ static void rockchip_pcie_remove(struct platform_device *pdev)
 	struct rockchip_pcie *rockchip = dev_get_drvdata(dev);
 	struct pci_host_bridge *bridge = pci_host_bridge_from_priv(rockchip);
 
+	pci_lock_rescan_remove();
 	pci_stop_root_bus(bridge->bus);
 	pci_remove_root_bus(bridge->bus);
+	pci_unlock_rescan_remove();
 	irq_domain_remove(rockchip->irq_domain);
 
 	rockchip_pcie_deinit_phys(rockchip);
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] PCI: rockchip: Protect root bus removal with rescan lock

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing cleanup of the chained IRQ handler leaves a dangling pointer to freed memory, causing a use-after-free if the interrupt fires after unbind.
- [High] Devm-managed shared IRQ handlers remain active while hardware clocks are disabled, risking a synchronous abort.
- [Medium] Clocks are disabled before regulators during remove, contrary to standard teardown order and the probe error path.
--

commit 785072a32823f4b0e136466862c1fafc7b9d2215
Author: Hans Zhang <18255117159@163.com>

PCI: rockchip: Protect root bus removal with rescan lock

Hold the pci_rescan_remove_lock lock while stopping and removing a root bus
to avoid racing with concurrent rescan or hotplug operations triggered via
sysfs. Such races may lead to use-after-free issues or system crashes.

Link: https://patch.msgid.link/20260521161822.132996-8-18255117159@163.com

> diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
> index ee1822ca01db3..d203c4876d304 100644
> --- a/drivers/pci/controller/pcie-rockchip-host.c
> +++ b/drivers/pci/controller/pcie-rockchip-host.c
> @@ -1012,8 +1012,10 @@ static void rockchip_pcie_remove(struct platform_device *pdev)
>  	struct rockchip_pcie *rockchip = dev_get_drvdata(dev);
>  	struct pci_host_bridge *bridge = pci_host_bridge_from_priv(rockchip);
>  
> +	pci_lock_rescan_remove();
>  	pci_stop_root_bus(bridge->bus);
>  	pci_remove_root_bus(bridge->bus);
> +	pci_unlock_rescan_remove();
>  	irq_domain_remove(rockchip->irq_domain);

[Severity: High]
This is a pre-existing issue, but does this code leave a dangling pointer to
freed memory for the chained IRQ handler?

The driver teardown path in rockchip_pcie_remove() misses the critical cleanup
step for the chained handler before freeing resources. It was originally set up
here:

drivers/pci/controller/pcie-rockchip-host.c:rockchip_pcie_setup_irq() {
...
	irq_set_chained_handler_and_data(irq,
					 rockchip_pcie_intx_handler,
					 rockchip);
...
}

Neither rockchip_pcie_remove() nor the rockchip_pcie_probe() error paths clear
this handler via irq_set_chained_handler_and_data(irq, NULL, NULL).

Since rockchip is devm-managed, it is freed by devres on device unbind. If an
interrupt fires after unbind, the IRQ subsystem retains a pointer to the
chained handler and the freed rockchip structure, causing a use-after-free
which likely results in a kernel panic.

>  
>  	rockchip_pcie_deinit_phys(rockchip);

[Severity: High]
This is a pre-existing issue, but do devm-managed shared IRQ handlers remain
active while hardware clocks are disabled?

Further down in rockchip_pcie_remove(), clocks are manually disabled well
before the devm-managed IRQ handlers are unregistered. The IRQ is requested as
shared and devm-managed:

drivers/pci/controller/pcie-rockchip-host.c:rockchip_pcie_setup_irq() {
...
	err = devm_request_irq(dev, irq, rockchip_pcie_subsys_irq_handler,
			       IRQF_SHARED, "pcie-sys", rockchip);
...
}

The handler unconditionally accesses device registers upon entry:

drivers/pci/controller/pcie-rockchip-host.c:rockchip_pcie_subsys_irq_handler() {
...
	reg = rockchip_pcie_read(rockchip, PCIE_CLIENT_INT_STATUS);
...
}

Because the shared IRQ remains active until the devres cleanup phase, which
happens after rockchip_pcie_remove() returns, any concurrent interrupt trigger
will attempt to read device registers with clocks disabled. Accessing hardware
registers while the APB/core clocks are disabled leads to a synchronous
external abort.

[Severity: Medium]
This isn't a bug introduced by this patch, but are the clocks disabled before
regulators during remove, contrary to the standard teardown order?

The code unconditionally calls rockchip_pcie_disable_clocks() prior to calling
regulator_disable() on the vpcie regulators. This contradicts the
rockchip_pcie_probe() error path, which correctly disables regulators before
disabling clocks.

Cutting clocks before cutting power regulators violates hardware power
sequencing and can leave the hardware in an undefined state.

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

[PATCH AUTOSEL 6.18-5.10] PCI: Avoid SBR for Qualcomm WCN6855/WCN7850 WiFi, SDX62/SDX65 modems

[Sasha Levin]

From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>

[ Upstream commit 6a4f64c3a3ada43e71ef1e06da89beb36bdaeefa ]

Some Qualcomm PCIe devices (WCN6855/WCN7850 WiFi cards, SDX62/SDX65 modems)
do not properly support Secondary Bus Reset (SBR).

Testing confirms this is device-specific, not deployment-specific:
MediaTek MT7925e successfully uses bus reset through the same passive
M.2-to-PCIe adapters where Qualcomm devices fail, proving PERST# is
properly wired through the adapters.

Prevent use of Secondary Bus Reset for these devices.

Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/all/20260609163649.319755-4-jtornosm@redhat.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...
Connection lost, reconnecting to https://agentn.us.api5.cursor.sh
(attempt 2)...
Retry attempt 2...
# Stable Backport Analysis: PCI Qualcomm SBR Quirk

**Local tree:** `v6.18.44` (6.18.44)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
**Record:** `[PCI] [avoid] Avoid Secondary Bus Reset (SBR) for Qualcomm
WCN6855/WCN7850 WiFi and SDX62/SDX65 modems`

### Step 1.2: Tags
**Record:**
- **Link:** `https://lore.kernel.org/all/20260609163649.319755-4-
  jtornosm@redhat.com`
- **Signed-off-by:** Jose Ignacio Tornos Martinez
  `<jtornosm@redhat.com>` (author)
- **Signed-off-by:** Bjorn Helgaas `<bhelgaas@google.com>` (PCI
  maintainer)
- No `Fixes:`, `Reported-by:`, `Cc: stable@vger.kernel.org`, `Tested-
  by:`, or `Reviewed-by:` tags
- Notable: maintainer sign-off from Bjorn Helgaas; part of v8 series
  `[PATCH v8 0/3]` per LWN

### Step 1.3: Body Analysis
**Record:**
- **Bug:** Qualcomm PCIe devices (WCN6855/WCN7850 WiFi, SDX62/SDX65
  modems) do not properly support Secondary Bus Reset
- **Symptom:** Bus reset fails/hangs on these devices; LWN series
  context describes VFIO passthrough reset failures and potential system
  hang when SBR is attempted (same failure class as existing Atheros
  quirk in `quirks.c`)
- **Root cause:** Device-specific hardware limitation, not
  adapter/wiring issue (MT7925e works on same M.2-to-PCIe adapters)
- **Fix:** Mark devices with `quirk_no_bus_reset` to set
  `PCI_DEV_FLAGS_NO_BUS_RESET`

### Step 1.4: Hidden Bug Fix?
**Record:** Yes — described as "avoid/prevent" rather than "fix", but it
is a hardware quirk preventing a known-broken reset path. Same pattern
as Atheros/Cavium/TI/ASM1164 quirks already in `quirks.c`, where SBR
causes link-down, inaccessible config space, and system hang.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **Files:** `drivers/pci/quirks.c` only (+3 lines)
- **Functions:** No function changes; adds 3 `DECLARE_PCI_FIXUP_HEADER`
  entries after Atheros quirks
- **Scope:** Single-file surgical hardware quirk addition

### Step 2.2: Code Flow Change
**Record:**
- **Before:** Qualcomm devices `0x17cb:0x1103`, `0x17cb:0x1107`,
  `0x17cb:0x0308` had no `NO_BUS_RESET` flag; `pci_reset_bus_function()`
  could probe/use SBR
- **After:** At PCI header fixup time, `quirk_no_bus_reset()` sets
  `PCI_DEV_FLAGS_NO_BUS_RESET`; `pci_parent_bus_reset()` and
  `pci_dev_reset_slot_function()` return `-ENOTTY` when flag is set
  (lines 4801, 4832 in `pci.c`)
- **Path affected:** PCI device reset enumeration and execution
  (`pci_init_reset_methods()`, `__pci_reset_function_locked()`), VFIO
  device reset, driver error recovery

### Step 2.3: Bug Mechanism
**Record:**
- **Category:** Hardware workaround / quirk
- **Mechanism:** Broken SBR on specific Qualcomm silicon; quirk prevents
  kernel from selecting a reset method that bricks the device or hangs
  the system. Analogous to Atheros quirk comment at lines 3767–3770:
  "config space of the device is never accessible again and typically
  causes the system to hang or reset"

### Step 2.4: Fix Quality
**Record:**
- Obviously correct: identical pattern to ~10 existing
  `quirk_no_bus_reset` entries in the same file
- Minimal: 3 `DECLARE_PCI_FIXUP_HEADER` lines
- Low regression risk: only affects listed device IDs; other reset
  methods (FLR, PM, device-specific) remain available if supported

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:**
- `quirk_no_bus_reset()` introduced in `c3e59ee4e7668` (2015-01-15, Alex
  Williamson) — long-established infrastructure
- Insertion point (after Atheros quirks, before Cavium) matches current
  tree layout exactly

### Step 3.2: Fixes: Tag
**Record:** Not applicable — no `Fixes:` tag. Bug is inherent to
hardware, not introduced by a specific kernel commit.

### Step 3.3: Related File History
**Record:**
- Recent similar quirks in this tree: ASM1164 (`a175a76147382`), Nvidia
  GB10 (`b8bd9fe67041c`)
- This commit is patch 3/3 of series "PCI: Add d3cold and device-
  specific reset for Qualcomm devices" (LWN v8 0/3). Patches 1–2 (d3cold
  reset method, Qualcomm device-specific reset) are **not** in this
  tree; patch 3 is standalone (only adds quirk entries, no code
  dependencies on patches 1–2)

### Step 3.4: Author Context
**Record:** Jose Ignacio Tornos Martinez — no prior PCI commits in this
6.18.44 tree; authored VFIO/PCI reset series merged to mainline v7.2
(June 2026). Bjorn Helgaas (PCI maintainer) signed off.

### Step 3.5: Dependencies
**Record:**
- **Standalone:** Yes — only uses existing `quirk_no_bus_reset` and
  `PCI_VENDOR_ID_QCOM`
- Patches 1–2 from the same series would improve VFIO reset capability
  but are **not prerequisites** for this quirk; LWN describes patch 3 as
  a "safety net" that independently prevents broken SBR

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original Discussion
**Record:**
- Direct lore fetch blocked (Anubis bot protection)
- LWN article found: [PCI: Add d3cold and device-specific reset for
  Qualcomm devices](https://lwn.net/Articles/1077236/) — covers full v8
  0/3 series
- `b4 dig -c <commit>` failed: commit not present in local repository
- Mainline merge: `44105c5d0a13` (pci/virtualization branch, 2026-06-23)

### Step 4.2: Reviewers
**Record:** CC list from LWN: `bhelgaas@google.com`, `alex@shazbot.org`
(VFIO), `linux-pci@`, `linux-wireless@`, `ath11k@`, `ath12k@`, `mhi@` —
appropriate subsystem coverage

### Step 4.3: Bug Report
**Record:** No formal bugzilla/syzbot report. Failure mode documented in
series cover letter: VFIO passthrough reset failures; device-specific
SBR breakage confirmed by comparative testing with MT7925e on same
adapters.

### Step 4.4: Series Context
**Record:**
- Patch 1/3: D3cold general reset method (not in 6.18.44)
- Patch 2/3: Qualcomm device-specific reset via D3cold (not in 6.18.44)
- Patch 3/3: **This commit** — disable broken SBR (standalone,
  backportable independently)

### Step 4.5: Stable List History
**Record:** No stable-list discussion found (lore blocked). Not a
negative signal per instructions.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
**Record:** `quirk_no_bus_reset()` (unchanged); reset path functions:
`pci_reset_bus_function()`, `pci_parent_bus_reset()`,
`pci_dev_reset_slot_function()`, `pci_slot_resettable()`

### Step 5.2: Callers
**Record:**
- `pci_init_reset_methods()` probes reset methods during device setup
- `__pci_reset_function_locked()` / `pci_reset_function()` used by VFIO,
  error handlers, sysfs `reset` attribute
- `pci_slot_resettable()` used during slot-level reset decisions
- All check `PCI_DEV_FLAGS_NO_BUS_RESET` — verified in `pci.c` lines
  4801, 4832, 5218, 5222, 5291, 5297

### Step 5.3: Callees
**Record:** `quirk_no_bus_reset()` only sets `dev->dev_flags |=
PCI_DEV_FLAGS_NO_BUS_RESET` — no allocations, locks, or I/O

### Step 5.4: Reachability
**Record:**
- Triggered during PCI enumeration (HEADER fixup) and whenever reset is
  attempted on these devices
- Userspace-reachable via VFIO passthrough, driver reload, error
  recovery, sysfs reset
- WiFi cards (WCN6855/WCN7850) and cellular modems (SDX62/SDX65) are
  commonly deployed hardware

### Step 5.5: Similar Patterns
**Record:** Identical pattern for Atheros (6 devices), Cavium, TI,
ASM1164, Nvidia — all `DECLARE_PCI_FIXUP_HEADER(...,
quirk_no_bus_reset)` in same section of `quirks.c`

---

## PHASE 6: CROSS-REFERENCE AGAINST LOCAL TREE (6.18.44)

### Step 6.1: Buggy Code Present?
**Record:** **Yes.** The quirk entries are **missing** from this tree.
Affected hardware **is supported:**
- `WCN6855` (`0x1103`): `drivers/net/wireless/ath/ath11k/pci.c` (since
  2021)
- `WCN7850` (`0x1107`): `drivers/net/wireless/ath/ath12k/pci.c` (since
  2022)
- `SDX62/SDX65` (`0x0308`): `drivers/bus/mhi/host/pci_generic.c` (SDX65
  since July 2025)
- `PCI_VENDOR_ID_QCOM` (`0x17cb`): `include/linux/pci_ids.h`

### Step 6.2: Backport Complications
**Record:** **Clean apply expected.** Target location (after Atheros
quirks at line 3778, before Cavium at 3785) matches the provided diff
exactly. No conflicting changes in that region.

### Step 6.3: Related Fixes Already Present?
**Record:** No — `git log --grep="Avoid SBR for Qualcomm"` returns
nothing. Qualcomm `quirk_no_bus_reset` entries for `0x1103`, `0x1107`,
`0x0308` absent from `quirks.c`.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem Criticality
**Record:** `drivers/pci/` — **CORE** subsystem. PCI reset affects all
PCI/PCIe devices; VFIO virtualization is a significant use case.

### Step 7.2: Activity
**Record:** Actively maintained — recent bus-reset quirks added (ASM1164
2024, Nvidia GB10 2025). Pattern is well-established and trusted.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who Is Affected
**Record:** Users of Qualcomm WCN6855/WCN7850 WiFi (ath11k/ath12k) and
SDX62/SDX65 cellular modems (MHI) — laptops, M.2 WiFi cards, embedded
modems, VFIO passthrough setups.

### Step 8.2: Trigger Conditions
**Record:**
- Any PCI reset attempt that would use Secondary Bus Reset (VFIO VM
  teardown, driver unbind/rebind, error recovery, manual sysfs reset)
- Not timing-dependent; deterministic hardware limitation
- Unprivileged users can trigger via VFIO if permitted by admin

### Step 8.3: Failure Mode Severity
**Record:** Without quirk: device becomes inaccessible, link down,
potential **system hang or reset** (per Atheros quirk precedent in same
file). Severity: **CRITICAL** for affected hardware.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** HIGH — prevents device bricking and system hang on common
  reset paths
- **Risk:** VERY LOW — 3-line quirk using proven infrastructure, scoped
  to 3 device IDs
- **Ratio:** Strongly favors backport

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backport:**
- Hardware quirk — established stable exception category
- Prevents system hang/device brick on SBR (CRITICAL severity)
- Surgical 3-line fix, obviously correct
- PCI maintainer (Bjorn Helgaas) signed off
- Affected devices fully supported in 6.18.44
- Infrastructure (`quirk_no_bus_reset`) present since 2015
- Identical to multiple existing stable-worthy quirks in same file
- Standalone — no dependency on patches 1–2 of the series

**AGAINST backport:**
- Part of a 3-patch series; patches 1–2 (alternative reset methods) not
  in tree — but patch 3 independently prevents catastrophic SBR failure
- No syzbot/fuzzer report — but hardware-specific, confirmed by author
  testing
- Without patches 1–2, VFIO reset may still fail for these devices — but
  that is strictly better than hanging

**Unresolved:** Direct lore thread unreadable (bot protection); `b4 dig`
unavailable (commit not in local repo).

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — proven quirk pattern; author
   tested device-specific behavior vs MT7925e
2. Fixes real bug affecting users? **PASS** — broken SBR on shipping
   Qualcomm hardware
3. Important issue? **PASS** — CRITICAL (hang, device brick)
4. Small and contained? **PASS** — 3 lines, 1 file
5. No new features/APIs? **PASS** — hardware quirk only
6. Can apply to local tree? **PASS** — clean apply to existing code

### Step 9.3: Exception Category
**Record:** **Hardware quirk/workaround** — automatic stable
qualification per instructions.

### Step 9.4: Decision Rationale
This commit adds PCI quirks preventing Secondary Bus Reset on Qualcomm
devices that do not support it. The 6.18.44 tree supports these devices
(ath11k, ath12k, MHI) but lacks the quirk, leaving users exposed to the
same failure mode documented for Atheros devices in the same file. The
fix is minimal, standalone, and follows a well-established pattern
already present in stable trees.

---

## Verification

- [Phase 1] Parsed subject, tags, body; identified as hardware quirk fix
- [Phase 1] LWN v8 0/3 series context retrieved from
  https://lwn.net/Articles/1077236/
- [Phase 2] Diff: 3 `DECLARE_PCI_FIXUP_HEADER` lines in
  `drivers/pci/quirks.c`
- [Phase 2] Read `quirk_no_bus_reset()` at lines 3741–3744
- [Phase 2] Read Atheros quirk hang description at lines 3767–3770
- [Phase 3] `git blame`: `quirk_no_bus_reset` from `c3e59ee4e7668`
  (2015)
- [Phase 3] `git log -S quirk_no_bus_reset`: 12 historical commits,
  pattern established
- [Phase 3] `git log --grep`: commit NOT in 6.18.44 tree
- [Phase 3] Confirmed patches 1–2 (d3cold, device-specific reset) NOT in
  tree via `git log --grep`
- [Phase 4] lore.kernel.org fetch blocked by Anubis
- [Phase 4] `b4 dig -c`: failed (commit not in local repo)
- [Phase 4] LWN series: patch 3/3 standalone safety net for broken SBR
- [Phase 4] GitHub merge `44105c5d0a13`: confirms mainline integration
  June 2026
- [Phase 5] `grep NO_BUS_RESET drivers/pci/pci.c`: 6 check sites
  verified
- [Phase 5] Read `pci_reset_fn_methods[]` at lines 5008–5017
- [Phase 5] Read `pci_parent_bus_reset()` at lines 4796–4812
- [Phase 6] `git describe HEAD`: v6.18.44
- [Phase 6] `make kernelversion`: 6.18.44
- [Phase 6] `grep 0x1103`: WCN6855 in `ath11k/pci.c`
- [Phase 6] `grep 0x1107`: WCN7850 in `ath12k/pci.c`
- [Phase 6] `grep 0x0308`: SDX65 in `mhi/host/pci_generic.c`
- [Phase 6] `grep PCI_VENDOR_ID_QCOM`: present in `pci_ids.h` as
  `0x17cb`
- [Phase 6] Confirmed quirk entries absent from current `quirks.c`
- [Phase 6] Target insertion point matches diff (after line 3778)
- [Phase 8] Hardware support dates: WCN6855 (2021), WCN7850 (2022),
  SDX65/0x0308 (2025) — all predate 6.18.44
- **UNVERIFIED:** Direct lore thread review (bot-blocked)
- **UNVERIFIED:** Explicit `Cc: stable` nomination in mailing list

**YES**

 drivers/pci/quirks.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 88d4a3f76bf3b..fbbdcbaf5aa01 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3776,6 +3776,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x003c, quirk_no_bus_reset);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0033, quirk_no_bus_reset);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0034, quirk_no_bus_reset);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x003e, quirk_no_bus_reset);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_QCOM, 0x1103, quirk_no_bus_reset); /* WCN6855 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_QCOM, 0x1107, quirk_no_bus_reset); /* WCN7850 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_QCOM, 0x0308, quirk_no_bus_reset); /* SDX62/SDX65 */
 
 /*
  * Root port on some Cavium CN8xxx chips do not successfully complete a bus
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] PCI: Avoid SBR for Qualcomm WCN6855/WCN7850 WiFi, SDX62/SDX65 modems

[sashiko-bot]

> From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> 
> [ Upstream commit 6a4f64c3a3ada43e71ef1e06da89beb36bdaeefa ]
> 
> Some Qualcomm PCIe devices (WCN6855/WCN7850 WiFi cards, SDX62/SDX65 modems)
> do not properly support Secondary Bus Reset (SBR).
> 
> Testing confirms this is device-specific, not deployment-specific:
> MediaTek MT7925e successfully uses bus reset through the same passive
> M.2-to-PCIe adapters where Qualcomm devices fail, proving PERST# is
> properly wired through the adapters.
> 
> Prevent use of Secondary Bus Reset for these devices.
> 
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Link: https://lore.kernel.org/all/20260609163649.319755-4-jtornosm@redhat.com
> Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

[PATCH AUTOSEL 6.18] misc: pci_endpoint_test: Validate BAR index in doorbell test

[Sasha Levin]

From: Carlos Bilbao <carlos.bilbao@kernel.org>

[ Upstream commit 854bd081c7680029d7886689f6bef8f740625fde ]

pci_endpoint_test_doorbell() reads the BAR number directly from an endpoint
test register and uses it as an index into test->bar[].  Add a defensive
bounds check before the dereference: positive values >= PCI_STD_NUM_BARS
are out of range, and NO_BAR (-1) as a negative signed value would slip
past an upper-bound-only check.

Signed-off-by: Carlos Bilbao (Lambda) <carlos.bilbao@kernel.org>
[mani: changed errno to -ERANGE]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260410230300.135631-2-carlos.bilbao@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `misc: pci_endpoint_test: Validate BAR index
in doorbell test`

**Local tree:** `v6.18.44-1-g2736c32da98b9` (kernel version **6.18.44**,
6.18.y stable series)

**Commit under review:** `854bd081c7680` (not yet in this tree; present
on `master`)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[misc: pci_endpoint_test]` `[Validate]` — defensive bounds
check on BAR index used in the doorbell test path.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Carlos Bilbao (Lambda), Manivannan Sadhasivam,
  Bjorn Helgaas
- **Link:** https://patch.msgid.link/20260410230300.135631-2-
  carlos.bilbao@kernel.org
- No `Fixes:`, `Reported-by:`, `Cc: stable@vger.kernel.org`, `Tested-
  by:`, or `Reviewed-by:` in the committed message
- Notable: PCI subsystem maintainers (Mani, Bjorn) signed off; no syzbot
  or user bug report

### Step 1.3: Body analysis
**Record:**
- **Bug:** `pci_endpoint_test_doorbell()` reads a BAR number from
  endpoint MMIO (`PCI_ENDPOINT_TEST_DB_BAR`) and uses it unvalidated as
  `test->bar[bar]`.
- **Symptom:** Out-of-range positive values (`>= PCI_STD_NUM_BARS`) or
  `NO_BAR (-1)` cause out-of-bounds indexing before `writel()`.
- **Root cause:** Missing lower/upper bounds check; an upper-bound-only
  check would miss negative values because `bar` is `enum pci_barno`
  (signed, with `NO_BAR = -1`).
- **Version info:** None in the message.

### Step 1.4: Hidden bug fix?
**Record:** Yes — explicitly a memory-safety bounds-check fix, not
cosmetic cleanup. Same bug class as the earlier ioctl underflow fix
(`1ad82f9db13d8`).

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **Files:** `drivers/misc/pci_endpoint_test.c` (+5 lines)
- **Function:** `pci_endpoint_test_doorbell()`
- **Scope:** Single-file, surgical fix

### Step 2.2: Code flow change
**Record:**
- **Before:** After re-reading `PCI_ENDPOINT_TEST_DB_BAR`, code
  immediately does `writel(data, test->bar[bar] + addr)`.
- **After:** Validates `bar < BAR_0 || bar >= PCI_STD_NUM_BARS`; logs
  error and returns `-ERANGE` on failure; only then dereferences
  `test->bar[bar]`.
- **Path affected:** Error/safety path inside doorbell test, reached via
  `ioctl(PCITEST_DOORBELL)`.

### Step 2.3: Bug mechanism
**Record:** **Category:** Out-of-bounds array access / buffer overflow.
- `test->bar` is `void __iomem *bar[PCI_STD_NUM_BARS]` (6 elements,
  indices 0–5).
- `pci_endpoint_test_readl()` returns `u32`; assigned to signed `enum
  pci_barno`.
- `bar == -1` (NO_BAR) → array underflow; `bar >= 6` → array overflow.
- Either can yield a garbage pointer passed to `writel()` → kernel oops
  or memory corruption.

### Step 2.4: Fix quality
**Record:** Obviously correct; mirrors the existing ioctl guard (`bar <=
NO_BAR || bar > BAR_5`). Minimal, no API changes. Low regression risk.
Does not add a NULL-bar check (consistent with other paths that validate
index separately).

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** Lines 895–897 introduced by `eefb83790a0dd` ("Add doorbell
test case", Frank Li, 2025-07-10). First appeared in **v6.17**. Bug
present since doorbell support landed.

### Step 3.2: Fixes: tag
**Record:** N/A — no `Fixes:` tag. Related introducing commit:
`eefb83790a0dd`, which is an ancestor of this 6.18.44 tree.

### Step 3.3: Related file history
**Record:**
- `eefb83790a0dd` — added doorbell test (v6.17+)
- `1ad82f9db13d8` — fixed ioctl array underflow for user-supplied BAR
  (same `NO_BAR` issue)
- `cc8e391067164`, `384b1b29481e3` — other doorbell-related cleanups
- Fix is standalone (patch 1/2 of a series); patch 2/2 only removes a
  dead register read (cleanup, not required for the bounds fix)

### Step 3.4: Author context
**Record:** Carlos Bilbao is a PCI endpoint contributor. Manivannan
Sadhasivam (PCI endpoint maintainer) applied the series. Dan Carpenter
previously fixed the parallel ioctl-path bug.

### Step 3.5: Dependencies
**Record:** No prerequisites. Doorbell code exists in this tree. `git
apply --check` on the patch succeeds cleanly against 6.18.44.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original discussion
**Record:** `b4 dig -c 854bd081c7680` → https://patch.msgid.link/2026041
0230300.135631-2-carlos.bilbao@kernel.org. Part of **v2 1/2** series.
Manivannan Sadhasivam replied "Applied, thanks!" No explicit stable
nomination found.

### Step 4.2: Reviewers
**Record:** `b4 dig -w`: CC'd to `mani@kernel.org`,
`kwilczynski@kernel.org`, `kishon@kernel.org`, `den@valinux.co.jp`,
`linux-pci@vger.kernel.org`. **Reviewed-by: Koichiro Den** on the
series.

### Step 4.3: Bug reports
**Record:** No external bug report, syzbot report, or crash log.
Proactive defensive fix identified during code review.

### Step 4.4: Series context
**Record:** 2-patch series. Only patch 1/2 (this commit) fixes the OOB
bug. Patch 2/2 removes an unused earlier BAR read.

### Step 4.5: Stable list history
**Record:** Not searched separately; no stable-list discussion found in
the patch thread.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `pci_endpoint_test_doorbell()` (modified), called from
`pci_endpoint_test_ioctl()`.

### Step 5.2: Callers
**Record:**
- `pci_endpoint_test_ioctl()` → `case PCITEST_DOORBELL:` →
  `pci_endpoint_test_doorbell(test)`
- Exposed via `misc_device` (`/dev/pci-endpoint-test.*`) through
  `unlocked_ioctl`
- Selftest: `tools/testing/selftests/pci_endpoint/pci_endpoint_test.c`
  calls `PCITEST_DOORBELL`

### Step 5.3: Callees
**Record:** `pci_endpoint_test_readl/writel`,
`wait_for_completion_timeout`, `writel()` to BAR-mapped MMIO.

### Step 5.4: Reachability
**Record:** Reachable from userspace via `ioctl()` on the misc device.
Requires access to the PCI endpoint test device node (typically root or
delegated permissions). Not triggerable by unprivileged users without
device access. With device access + buggy/malicious endpoint firmware
returning an invalid BAR register value, the OOB path is reachable.

### Step 5.5: Similar patterns
**Record:** Ioctl path already has equivalent validation at line 940:
```940:941:drivers/misc/pci_endpoint_test.c
                if (bar <= NO_BAR || bar > BAR_5)
                        goto ret;
```
Doorbell path lacks this guard — an inconsistency the patch corrects.

---

## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE (6.18.44)

### Step 6.1: Buggy code present?
**Record:** **Yes.** `pci_endpoint_test_doorbell()` at lines 895–897
performs unchecked `test->bar[bar]` dereference. Doorbell support
(`eefb83790a0dd`) is an ancestor of HEAD (landed in v6.17, present in
6.18.44).

### Step 6.2: Backport complications
**Record:** **Clean apply.** `git apply --check` passes. No structural
conflicts; line numbers differ but context matches.

### Step 6.3: Related fixes already present?
**Record:** Ioctl underflow fix (`1ad82f9db13d8`) is in this tree. The
doorbell-path BAR validation fix (`854bd081c7680`) is **not** in this
tree (only on `master`).

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem criticality
**Record:** **drivers/misc** — PCI Endpoint Test driver
(`CONFIG_PCI_ENDPOINT_TEST`). **PERIPHERAL** — host-side test driver for
PCI endpoint development (TI K3, Rockchip, etc.). Not a core subsystem,
but kernel code reachable from userspace ioctl.

### Step 7.2: Activity
**Record:** Actively maintained; multiple recent fixes in the same file
(IRQ range checks, ioctl underflow, integer overflow prevention).

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who is affected
**Record:** Users with `CONFIG_PCI_ENDPOINT_TEST` enabled who run the
doorbell selftest against PCI endpoint hardware. Primarily embedded/SoC
developers, not typical server/desktop workloads.

### Step 8.2: Trigger conditions
**Record:** `ioctl(PCITEST_DOORBELL)` after doorbell enable, when
endpoint MMIO reports `PCI_ENDPOINT_TEST_DB_BAR` outside [0, 5] or as
-1. Unlikely in correct firmware, but possible with bugs or during
bring-up. Requires device-node access.

### Step 8.3: Failure mode severity
**Record:** Out-of-bounds pointer dereference in `writel()` → **kernel
oops / potential memory corruption**. **Severity: HIGH** if triggered;
**likelihood: LOW** (niche driver, privileged access, depends on
endpoint behavior).

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** Prevents kernel crash from a real OOB bug; aligns
  doorbell path with already-fixed ioctl path.
- **Risk:** Very low — 5-line bounds check, maintainer-reviewed, clean
  apply.
- **Ratio:** Favorable for backport despite narrow exposure.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Real out-of-bounds array index bug (underflow and overflow)
- Can cause kernel oops
- Small (5 lines), obviously correct, applies cleanly
- Buggy code confirmed in 6.18.44 since v6.17 doorbell addition
- PCI maintainers signed off; parallel ioctl fix already in this tree
- Self-contained; no dependencies

**AGAINST backport:**
- Niche test driver (`CONFIG_PCI_ENDPOINT_TEST`)
- Requires privileged device access
- No syzbot/user crash reports
- Invalid BAR comes from endpoint MMIO, not direct userspace input
- Limited production impact

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

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — simple bounds check;
   selftests exercise doorbell path; maintainer applied.
2. Fixes a real bug? **PASS** — OOB array indexing.
3. Important issue? **PASS** — kernel crash on invalid index (HIGH
   severity, lower exposure).
4. Small and contained? **PASS** — 5 lines, one function.
5. No new features/APIs? **PASS**.
6. Can apply to local tree? **PASS** — clean apply verified.

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

### Step 9.4: Decision rationale
For **6.18.44**, the doorbell test exists and has had an unchecked BAR
index since v6.17. This is the same class of memory-safety bug already
fixed on the ioctl path in this tree. The fix is minimal, maintainer-
approved, and prevents a kernel oops. Narrow driver scope lowers urgency
but does not negate that it is a real, reachable crash fix in code that
is present and active in this stable tree.

---

## Verification

- **[Phase 1]** Parsed commit `854bd081c7680` message and tags via `git
  show`
- **[Phase 1]** No syzbot/Reported-by; Link tag present; Bjorn Helgaas
  and Mani SOBs confirmed
- **[Phase 2]** Read `pci_endpoint_test_doorbell()` at lines 857–922;
  confirmed unchecked `test->bar[bar]` at line 897
- **[Phase 2]** Confirmed `test->bar[PCI_STD_NUM_BARS]` and `NO_BAR =
  -1` at lines 108–121
- **[Phase 3]** `git blame -L 895,897`: introduced by `eefb83790a0dd`
  (2025-07-10)
- **[Phase 3]** `git log -20 -- drivers/misc/pci_endpoint_test.c`:
  related ioctl fix `1ad82f9db13d8` present
- **[Phase 3]** `git tag --contains eefb83790a0dd`: first in **v6.17**
- **[Phase 3]** `git merge-base --is-ancestor`: doorbell IN tree; fix
  `854bd081c7680` NOT in HEAD; ioctl fix IN HEAD
- **[Phase 4]** `b4 dig -c 854bd081c7680`: lore URL found
- **[Phase 4]** `b4 dig -m /tmp/doorbell_bar.mbox`: v2 1/2 series;
  Reviewed-by Den; Mani "Applied, thanks!"
- **[Phase 4]** No stable nomination in thread
- **[Phase 5]** Traced call chain: `pci_endpoint_test_ioctl` →
  `PCITEST_DOORBELL` → `pci_endpoint_test_doorbell`
- **[Phase 5]** Grep `PCITEST_DOORBELL`: ioctl case at line 974,
  selftest at
  `tools/testing/selftests/pci_endpoint/pci_endpoint_test.c:261`
- **[Phase 5]** Confirmed ioctl bounds check at line 940 (`bar <= NO_BAR
  || bar > BAR_5`)
- **[Phase 6]** `git describe HEAD`: v6.18.44; `make kernelversion`:
  6.18.44
- **[Phase 6]** `git apply --check` on patch: **clean apply**
- **[Phase 6]** Read probe: `test` allocated with `devm_kzalloc` (line
  1019); `test->bar[]` sized `PCI_STD_NUM_BARS`
- **[Phase 8]** `CONFIG_PCI_ENDPOINT_TEST` in `drivers/misc/Kconfig:482`
  — tristate host-side PCI endpoint test driver

**YES**The background lookups finished and match the earlier analysis:

- **Commit hash:** `854bd081c7680` — `misc: pci_endpoint_test: Validate
  BAR index in doorbell test`
- **Location:** on `master` (via merge `ae385ca812325`), **not** in the
  checked-out **6.18.44** tree
- **Local state:** the doorbell path still does an unchecked
  `test->bar[bar]` dereference; the patch applies cleanly here

**Verdict remains YES** for backport to this 6.18.y tree — small bounds-
check fix for a real OOB bug in code that’s already present since v6.17.

 drivers/misc/pci_endpoint_test.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 1c0fd185114fc..43e2282f8a76e 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -893,6 +893,11 @@ static int pci_endpoint_test_doorbell(struct pci_endpoint_test *test)
 	pci_endpoint_test_writel(test, PCI_ENDPOINT_TEST_STATUS, 0);
 
 	bar = pci_endpoint_test_readl(test, PCI_ENDPOINT_TEST_DB_BAR);
+	if (bar < BAR_0 || bar >= PCI_STD_NUM_BARS) {
+		dev_err(dev, "BAR %d reported by endpoint out of range [0, %u]\n",
+			bar, PCI_STD_NUM_BARS - 1);
+		return -ERANGE;
+	}
 
 	writel(data, test->bar[bar] + addr);
 
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18] misc: pci_endpoint_test: Validate BAR index in doorbell test

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [Medium] The newly added early return bypasses the COMMAND_DISABLE_DOORBELL cleanup step, leaving the endpoint device in an inconsistent state and causing resource leaks.

Pre-existing issues:
- [Critical] The endpoint-provided `addr` offset is not validated against the actual size of the BAR memory region, allowing an arbitrary out-of-bounds write.
- [High] The driver verifies the `bar` index bounds but fails to check if the targeted BAR is actually mapped (non-NULL) before dereferencing it via `writel()`.
--

commit 7fede1d6ad3da3ad8055d4fe4ae5cd8853f975be
Author: Carlos Bilbao <carlos.bilbao@kernel.org>

misc: pci_endpoint_test: Validate BAR index in doorbell test

pci_endpoint_test_doorbell() reads the BAR number directly from an endpoint
test register and uses it as an index into test->bar[]. Add a defensive
bounds check before the dereference.

Link: https://patch.msgid.link/20260410230300.135631-2-carlos.bilbao@kernel.org

> diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
> index 1c0fd185114fc..43e2282f8a76e 100644
> --- a/drivers/misc/pci_endpoint_test.c
> +++ b/drivers/misc/pci_endpoint_test.c
> @@ -893,6 +893,11 @@ static int pci_endpoint_test_doorbell(struct pci_endpoint_test *test)
>  	pci_endpoint_test_writel(test, PCI_ENDPOINT_TEST_STATUS, 0);
>  
>  	bar = pci_endpoint_test_readl(test, PCI_ENDPOINT_TEST_DB_BAR);
> +	if (bar < BAR_0 || bar >= PCI_STD_NUM_BARS) {
> +		dev_err(dev, "BAR %d reported by endpoint out of range [0, %u]\n",
> +			bar, PCI_STD_NUM_BARS - 1);
> +		return -ERANGE;

[Severity: Medium]
In drivers/misc/pci_endpoint_test.c, does this early return in
pci_endpoint_test_doorbell() bypass the COMMAND_DISABLE_DOORBELL cleanup
step?

If a userspace application invokes the PCITEST_DOORBELL ioctl and the
endpoint reports an invalid BAR index, this early return skips sending the
disable command to the endpoint. It appears this leaves the device in an
inconsistent state and leaks the memory and MSI IRQs allocated when the
doorbell was enabled.

> +	}
>  
>  	writel(data, test->bar[bar] + addr);

[Severity: High]
This is a pre-existing issue in pci_endpoint_test_doorbell(), but does this
code check if the targeted BAR is actually mapped before dereferencing it?

If a userspace application triggers the PCITEST_DOORBELL ioctl and the
endpoint returns a valid BAR index that was not successfully mapped during
probe (for example, if it was not an IORESOURCE_MEM), this writel() call
could result in a NULL pointer dereference.

[Severity: Critical]
This is also a pre-existing issue, but is the endpoint-provided addr offset
validated against the actual size of the BAR memory region?

A malicious or buggy endpoint can provide an arbitrary 32-bit addr offset
that exceeds the size of the mapped BAR. When writel() executes, it could
perform an out-of-bounds memory write, potentially corrupting adjacent
kernel memory or memory-mapped IO regions.

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

[PATCH AUTOSEL 6.18-6.1] PCI: Wait for device readiness after D3hot -> D0uninitialized transition

[Sasha Levin]

From: Bjorn Helgaas <helgaas@kernel.org>

[ Upstream commit 41167a1e98536b4baf0846fd259c8124bd1c4e1b ]

For a device that advertises No_Soft_Reset == 0, a transition from D3hot to
D0uninitialized is a soft reset, and the resulting internal device state is
undefined.

Per PCIe r7.0, sec 2.3.1, a transition from D3hot to D0uninitialized
mandates a minimum 10 ms delay before accessing the device. Following this
delay, the device is permitted to respond to initial configuration requests
with a Request Retry Status (RRS) completion status if it needs more time
to initialize.

Call pci_dev_wait() after pci_power_up() performs a D3hot->D0uninitialized
transition to ensure the device is ready to accept config accesses, as is
done after the similar transition in pci_pm_reset().

If the device is already ready, this is essentially a no-op except for one
additional config read.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Link: https://patch.msgid.link/20260518191220.636213-3-bhelgaas@google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: PCI D3hot→D0 Readiness Wait

**Local tree:** `v6.18.43` (Linux 6.18.43)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
**Record:** `[PCI]` `[Wait]` — After a D3hot→D0uninitialized power
transition, wait for the device to become configuration-ready before
proceeding.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Bjorn Helgaas `<bhelgaas@google.com>` (author, PCI
  maintainer)
- **Reviewed-by:** Rafael J. Wysocki `<rafael@kernel.org>` (PM
  maintainer)
- **Link:**
  https://patch.msgid.link/20260518191220.636213-3-bhelgaas@google.com
- No Fixes:, Reported-by:, Tested-by:, Cc: stable, or syzbot tags
- Notable: Reviewed by the ACPI/PM maintainer; part of a 2-patch v2
  series (patch 2/2)

### Step 1.3: Body Analysis
**Record:**
- **Bug:** After D3hot→D0uninitialized (soft reset when `No_Soft_Reset
  == 0`), the kernel waits the mandatory 10 ms (`pci_dev_d3_sleep`) but
  does not poll until the device stops returning Request Retry Status
  (RRS) or error responses.
- **Symptom:** Premature config-space access after power-up; BAR restore
  / state reads may see `~0` (`PCI_ERROR_RESPONSE`) or RRS, causing
  resume/probe failures.
- **Root cause:** `pci_power_up()` lacked the `pci_dev_wait()` call that
  `pci_pm_reset()` already performs after the same transition.
- **Spec reference:** PCIe r7.0 §2.3.1.

### Step 1.4: Hidden Bug Fix?
**Record:** No — this is an explicit, well-described correctness bug fix
for a spec-mandated timing gap, not disguised cleanup.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **File:** `drivers/pci/pci.c` (+22 / -2 lines in series; this commit
  ~20 net lines)
- **Function modified:** `pci_power_up()`
- **Scope:** Single-file, surgical fix in one function

### Step 2.2: Code Flow Change
**Record:**
- **Hunk 1 (comment block):** Documents platform vs. PM-capability
  power-up paths.
- **Hunk 2 (D3hot branch):**
  - **Before:** `pci_dev_d3_sleep(dev);` then immediately mark device
    D0.
  - **After:** `pci_dev_d3_sleep(dev);` then, if soft-reset applies
    (`!(pmcsr & PCI_PM_CTRL_NO_SOFT_RESET)`), call `pci_dev_wait()`. On
    failure, set `current_state = PCI_D3cold` and return `-EIO`.
- **Affected path:** D3hot→D0 power-up error/normal resume path inside
  `pci_power_up()`.

### Step 2.3: Bug Mechanism
**Record:**
- **Category:** Logic / spec-compliance / timing correctness fix
- **Mechanism:** After mandatory 10 ms delay, device may still respond
  with RRS or synthesized `~0` on config reads. Without polling via
  `pci_dev_wait()`, subsequent `pci_restore_bars()` /
  `pci_restore_state()` can operate on garbage. The fix mirrors the
  existing `pci_pm_reset()` pattern at line 4456.

### Step 2.4: Fix Quality
**Record:**
- **Quality:** High — reuses proven `pci_dev_wait()` infrastructure
  already used for FLR, AF_FLR, and `pci_pm_reset()`.
- **Regression risk:** Very low — if device is already ready, one extra
  config read (author's own statement). Worst case adds up to 60 s wait
  on genuinely broken hardware, then clean `-EIO` failure instead of
  proceeding with bad state.
- **No API changes, no new symbols.**

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** Lines 1349–1352 in this tree (`pci_dev_d3_sleep` only, no
wait) are present in current `pci_power_up()`. `pci_dev_wait()` exists
at line 1209 and is already called from `pci_pm_reset()` at line 4456.
This tree's git history is shallow (single upstream-marker commit per
file), so exact introduction SHA of the missing wait cannot be
determined locally.

### Step 3.2: Fixes: Tag
**Record:** N/A — no Fixes: tag in commit message.

### Step 3.3: Related Changes
**Record:** Part of v2 2-patch series by Bjorn Helgaas (May 2026):
1. `PCI: Log device readiness timeouts as errors` — changes `pci_warn` →
   `pci_err` in `pci_dev_wait()` timeout path
2. **This commit** — adds `pci_dev_wait()` to `pci_power_up()`

Patch 2 is standalone; patch 1 is a logging improvement only.

### Step 3.4: Author Context
**Record:** Bjorn Helgaas is the PCI subsystem maintainer. Rafael
Wysocki (PM maintainer) reviewed. Author applied series to `pci/reset`
for v7.2 per mailing list follow-up.

### Step 3.5: Dependencies
**Record:** No code dependencies on patch 1/2. Requires only existing
`pci_dev_wait()`, `pci_dev_d3_sleep()`, `PCIE_RESET_READY_POLL_MS`, and
`PCI_PM_CTRL_NO_SOFT_RESET` — all present in this 6.18.43 tree. **Can
apply standalone: YES.**

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original Discussion
**Record:**
- Series cover: https://lkml.iu.edu/2605.2/03907.html
- This patch (v2 2/2): https://lkml.iu.edu/2605.2/03911.html
- v1 was a single-patch submission (May 14, 2026); v2 added error
  handling and companion logging patch
- No NAKs found; maintainer applied to `pci/reset` for v7.2
- No explicit "Cc: stable" nomination found in available threads

### Step 4.2: Reviewers
**Record:** CC list included Rafael Wysocki, Lukas Wunner, Mika
Westerberg, Alex Williamson, Mario Limonciello, and other PCI/PM
experts. Rafael Wysocki provided Reviewed-by.

### Step 4.3: Bug Report
**Record:** No external bug report or syzbot link. Bug identified via
spec compliance analysis and inconsistency with `pci_pm_reset()`
behavior.

### Step 4.4: Series Context
**Record:** 2-patch series; only patch 2/2 is under review. Patch 1 is
optional for functionality.

### Step 4.5: Stable List History
**Record:** No stable-list discussion found for this specific fix.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
**Record:** `pci_power_up()` (modified), `pci_dev_wait()` (called),
`pci_set_full_power_state()` (caller),
`pci_pm_power_up_and_verify_state()` (direct caller)

### Step 5.2: Callers of `pci_power_up()`
**Record:**
1. `pci_set_full_power_state()` → `__pci_set_power_state()` when `state
   == PCI_D0` — **system/runtime resume path** (`pci_set_power_state()`
   is widely used across drivers)
2. `pci_pm_power_up_and_verify_state()` → called from:
   - `pci_pm_init()` — boot enumeration (devices left in D3hot by BIOS)
   - `pci_pm_default_resume_early()` — suspend resume
   - `pci_pm_thaw_noirq()` — hibernate thaw

### Step 5.3: Callees
**Record:** `platform_pci_set_power_state()`,
`pci_read/write_config_word()`, `pci_dev_d3_sleep()`, `pci_dev_wait()` —
all standard PCI PM primitives.

### Step 5.4: Reachability
**Record:** Triggered on every D3hot→D0 transition through
`pci_power_up()` for devices without `No_Soft_Reset`. This is a
**common** path during suspend/resume, hibernate, and boot. Userspace
can indirectly trigger via runtime PM (`pci_set_power_state`).

### Step 5.5: Similar Patterns
**Record:** `pci_pm_reset()` at lines 4448–4456 already does
`pci_dev_d3_sleep()` + `pci_dev_wait()` after D3hot→D0. This commit
closes the same gap in `pci_power_up()`.

---

## PHASE 6: CROSS-REFERENCE AGAINST LOCAL TREE (6.18.43)

### Step 6.1: Buggy Code Present?
**Record:** **YES.** Current `pci_power_up()` at lines 1349–1350:

```1349:1352:drivers/pci/pci.c
        if (state == PCI_D3hot)
                pci_dev_d3_sleep(dev);
        else if (state == PCI_D2)
                udelay(PCI_PM_D2_DELAY);
```

No `pci_dev_wait()` call. `pci_dev_wait()` and `pci_pm_reset()`'s
correct usage both exist in this tree.

### Step 6.2: Backport Complications
**Record:** **Clean apply expected.** No refactoring conflicts visible.
`pci_power_up()` structure matches the patch base (`5a9af0bb2c71` index
in patch matches current code layout).

### Step 6.3: Related Fixes Already Present?
**Record:** No — `git log --grep` found no prior "device readiness" or
equivalent fix in this tree. Patch 1 (warn→err) also not present (line
1261 still uses `pci_warn`).

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem Criticality
**Record:** **PCI core** (`drivers/pci/pci.c`) — **CORE** subsystem.
Affects all PCI/PCIe devices on resume and boot.

### Step 7.2: Activity Level
**Record:** Mature, actively maintained subsystem. PM paths are long-
standing; this is a gap in an established code path, not new subsystem
code.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who Is Affected
**Record:** All systems with PCI devices that:
- Support native PM (`pm_cap` present)
- Have `No_Soft_Reset == 0` (soft reset on D3hot→D0)
- Need more than 10 ms to become configuration-ready after soft reset

This includes many laptops (BIOS leaves devices in D3hot at boot, per
existing comment at lines 1402–1405) and suspend/resume scenarios.

### Step 8.2: Trigger Conditions
**Record:**
- **When:** D3hot→D0 power-up via `pci_power_up()` with soft-reset
  semantics
- **Likelihood:** Intermittent — depends on device initialization time;
  more likely on slower devices or under load
- **Userspace trigger:** Indirect via runtime PM resume; unprivileged
  users can trigger device PM on assigned devices

### Step 8.3: Failure Mode Severity
**Record:**
- **Failure mode:** Failed resume, incorrect BAR restoration, driver
  probe failure, possible oops if driver proceeds with bad config
- **Severity:** **HIGH** for affected devices (resume failure renders
  hardware unusable until reboot); **MEDIUM** population-wide (only
  soft-reset-capable devices that are slow to initialize)

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** HIGH — fixes real resume/boot failures on affected
  hardware; aligns with PCIe spec and existing `pci_pm_reset()` behavior
- **Risk:** VERY LOW — minimal diff, proven helper, no-op on ready
  devices
- **Ratio:** Strongly favors backport

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backport:**
- Fixes a real spec-compliance bug in a core resume path
- Can cause suspend/resume and boot failures on affected PCI devices
- Small, surgical, obviously correct (mirrors `pci_pm_reset()`)
- PCI maintainer authorship + PM maintainer review
- All required infrastructure exists in 6.18.43
- Buggy code confirmed present in this tree

**AGAINST backport:**
- No user bug reports or syzbot reproduction (theoretical/spec-driven
  fix)
- Part of 2-patch series (patch 1 is logging-only, not required)
- Adds latency (up to 60 s) only on genuinely broken/unresponsive
  devices

**Unresolved:** Exact kernel version when `pci_power_up()` was
introduced without the wait (shallow git history in this stable tree).

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — mirrors existing
   `pci_pm_reset()` pattern; reviewed by PM maintainer
2. Fixes a real bug affecting users? **PASS** — spec-mandated readiness
   gap on D3hot→D0 resume
3. Important issue? **PASS** — resume/probe failures (HIGH for affected
   devices)
4. Small and contained? **PASS** — ~20 lines, one function, one file
5. No new features or APIs? **PASS**
6. Can apply to local tree? **PASS** — buggy code and all dependencies
   present in 6.18.43

### Step 9.3: Exception Categories
**Record:** None (not a quirk/DT/build/doc fix — a core correctness bug
fix).

### Step 9.4: Decision Rationale

This commit closes a long-standing gap where `pci_power_up()` — used on
boot, suspend resume, and hibernate thaw — did not wait for device
readiness after a D3hot→D0 soft reset, even though `pci_pm_reset()`
already did. The fix is minimal, uses existing infrastructure, has
maintainer review, and addresses a real failure mode (premature config
access after power-up) that can break device resume on affected
hardware. The risk of backporting is negligible since ready devices pay
only one extra config read.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body from user-provided commit
  message
- **[Phase 1]** Confirmed Reviewed-by: Rafael Wysocki; no
  syzbot/Reported-by
- **[Phase 2]** Read current `pci_power_up()` at lines 1303–1360:
  missing `pci_dev_wait()` confirmed
- **[Phase 2]** Read `pci_pm_reset()` at lines 4429–4457: has
  `pci_dev_wait()` after D3hot→D0
- **[Phase 2]** Read `pci_dev_wait()` at lines 1209–1290: polling logic
  with 60 s timeout confirmed
- **[Phase 3]** `git describe HEAD`: v6.18.43-1-gc7f0dac02d232
- **[Phase 3]** `git blame -L 1340,1365 drivers/pci/pci.c`: D3hot branch
  lacks wait
- **[Phase 3]** `git log --grep`: no prior fix for this issue in tree
- **[Phase 4]** Web search: found v2 series cover at
  lkml.iu.edu/2605.2/03907.html
- **[Phase 4]** Web search: found patch 2/2 at
  lkml.iu.edu/2605.2/03911.html — diff matches provided commit
- **[Phase 4]** Web search: found patch 1/2 at
  lkml.iu.edu/2605.2/03901.html — logging only, not a prerequisite
- **[Phase 4]** Web search: maintainer applied to pci/reset for v7.2
  (openwall list, May 22 2026)
- **[Phase 4]** lore.kernel.org direct fetch: 403 Forbidden (used
  lkml.iu.edu mirror instead)
- **[Phase 4]** b4 dig: no commit hash available in tree (commit not yet
  applied); could not run `b4 dig -c`
- **[Phase 5]** `grep pci_power_up`: callers in
  `pci_set_full_power_state()`, `pci_pm_power_up_and_verify_state()`
- **[Phase 5]** Read `pci-driver.c` lines 541–572, 1103–1118:
  resume/thaw paths call `pci_pm_power_up_and_verify_state()`
- **[Phase 5]** Read `pci.c` line 3196: boot path `pci_pm_init()` calls
  `pci_pm_power_up_and_verify_state()`
- **[Phase 6]** Confirmed `PCI_PM_CTRL_NO_SOFT_RESET`,
  `PCIE_RESET_READY_POLL_MS`, `pci_dev_d3_sleep()` all exist
- **[Phase 6]** Line 1261 still has `pci_warn` (patch 1 not applied) —
  patch 2 applies independently
- **[Phase 8]** Assessed failure mode: resume/probe failure on slow-to-
  initialize soft-reset devices

**YES**

 drivers/pci/pci.c | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 439045ab69319..c533111186f70 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1305,7 +1305,18 @@ int pci_power_up(struct pci_dev *dev)
 	bool need_restore;
 	pci_power_t state;
 	u16 pmcsr;
+	int ret;
 
+	/*
+	 * When setting power state to D0, platform_pci_set_power_state()
+	 * ensures main power is on.  If it puts the device in D0, it also
+	 * completes any required delays after the transition; if it leaves
+	 * the device in D1, D2, or D3hot, we use the PM Capability to
+	 * transition to D0.
+	 *
+	 * In all cases, the device is either Configuration-Ready or
+	 * inaccessible upon return.
+	 */
 	platform_pci_set_power_state(dev, PCI_D0);
 
 	if (!dev->pm_cap) {
@@ -1346,10 +1357,19 @@ int pci_power_up(struct pci_dev *dev)
 	pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, 0);
 
 	/* Mandatory transition delays; see PCI PM 1.2. */
-	if (state == PCI_D3hot)
+	if (state == PCI_D3hot) {
 		pci_dev_d3_sleep(dev);
-	else if (state == PCI_D2)
+		if (!(pmcsr & PCI_PM_CTRL_NO_SOFT_RESET)) {
+			ret = pci_dev_wait(dev, "power up D3hot->D0uninitialized",
+					   PCIE_RESET_READY_POLL_MS);
+			if (ret) {
+				dev->current_state = PCI_D3cold;
+				return -EIO;
+			}
+		}
+	} else if (state == PCI_D2) {
 		udelay(PCI_PM_D2_DELAY);
+	}
 
 end:
 	dev->current_state = PCI_D0;
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-6.1] PCI: Wait for device readiness after D3hot -> D0uninitialized transition

[sashiko-bot]

> From: Bjorn Helgaas <helgaas@kernel.org>
> 
> [ Upstream commit 41167a1e98536b4baf0846fd259c8124bd1c4e1b ]
> 
> For a device that advertises No_Soft_Reset == 0, a transition from D3hot to
> D0uninitialized is a soft reset, and the resulting internal device state is
> undefined.
> 
> Per PCIe r7.0, sec 2.3.1, a transition from D3hot to D0uninitialized
> mandates a minimum 10 ms delay before accessing the device. Following this
> delay, the device is permitted to respond to initial configuration requests
> with a Request Retry Status (RRS) completion status if it needs more time
> to initialize.
> 
> Call pci_dev_wait() after pci_power_up() performs a D3hot->D0uninitialized
> transition to ensure the device is ready to accept config accesses, as is
> done after the similar transition in pci_pm_reset().
> 
> If the device is already ready, this is essentially a no-op except for one
> additional config read.
> 
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
> Link: https://patch.msgid.link/20260518191220.636213-3-bhelgaas@google.com
> Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

[PATCH AUTOSEL 6.18-6.1] PCI: switchtec: Add Gen6 Device IDs

[Sasha Levin]

From: Ben Reed <Ben.Reed@microchip.com>

[ Upstream commit 5e6c21c56998e1e58d2f314e70779989ea0fee5d ]

Add device IDs for the next generation of switchtec products.

No changes to the driver were required with the new version of the
hardware.

[logang: rewrote commit message]

Signed-off-by: Ben Reed <Ben.Reed@microchip.com>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260505161633.67454-1-logang@deltatee.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The background history search finished. In this 6.18.43 checkout, `git
log -S 'SWITCHTEC_GEN5'` and `git log --grep='switchtec: Add'` didn’t
turn up individual Switchtec ID commits — only the bulk merge
`5d324e5159d9e` and unrelated history. That matches what we already saw:
Gen3/4/5 support is present, but this tree doesn’t have granular
Switchtec commit history.

That doesn’t change the backport assessment: this is a standard PCI
device ID addition for an existing driver, it fits the stable “just add
a device ID” rule, and it should apply cleanly to 6.18.43.

**YES**

 drivers/pci/switch/switchtec.c | 16 ++++++++++++++++
 include/linux/switchtec.h      |  1 +
 2 files changed, 17 insertions(+)

diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 5ff84fb8fb0f4..f32ddfa79da99 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -1852,6 +1852,22 @@ static const struct pci_device_id switchtec_pci_tbl[] = {
 	SWITCHTEC_PCI_DEVICE(0x5552, SWITCHTEC_GEN5),  /* PAXA 52XG5 */
 	SWITCHTEC_PCI_DEVICE(0x5536, SWITCHTEC_GEN5),  /* PAXA 36XG5 */
 	SWITCHTEC_PCI_DEVICE(0x5528, SWITCHTEC_GEN5),  /* PAXA 28XG5 */
+	SWITCHTEC_PCI_DEVICE(0x6048, SWITCHTEC_GEN6),  /* PFXs 48XG6 */
+	SWITCHTEC_PCI_DEVICE(0x6064, SWITCHTEC_GEN6),  /* PFXs 64XG6 */
+	SWITCHTEC_PCI_DEVICE(0x6044, SWITCHTEC_GEN6),  /* PFXs 144XG6 */
+	SWITCHTEC_PCI_DEVICE(0x6060, SWITCHTEC_GEN6),  /* PFXs 160XG6 */
+	SWITCHTEC_PCI_DEVICE(0x6148, SWITCHTEC_GEN6),  /* PSXs 48XG6 */
+	SWITCHTEC_PCI_DEVICE(0x6164, SWITCHTEC_GEN6),  /* PSXs 64XG6 */
+	SWITCHTEC_PCI_DEVICE(0x6144, SWITCHTEC_GEN6),  /* PSXs 144XG6 */
+	SWITCHTEC_PCI_DEVICE(0x6160, SWITCHTEC_GEN6),  /* PSXs 160XG6 */
+	SWITCHTEC_PCI_DEVICE(0x6248, SWITCHTEC_GEN6),  /* PFX 48XG6 */
+	SWITCHTEC_PCI_DEVICE(0x6264, SWITCHTEC_GEN6),  /* PFX 64XG6 */
+	SWITCHTEC_PCI_DEVICE(0x6244, SWITCHTEC_GEN6),  /* PFX 144XG6 */
+	SWITCHTEC_PCI_DEVICE(0x6260, SWITCHTEC_GEN6),  /* PFX 160XG6 */
+	SWITCHTEC_PCI_DEVICE(0x6348, SWITCHTEC_GEN6),  /* PSX 48XG6 */
+	SWITCHTEC_PCI_DEVICE(0x6364, SWITCHTEC_GEN6),  /* PSX 64XG6 */
+	SWITCHTEC_PCI_DEVICE(0x6344, SWITCHTEC_GEN6),  /* PSX 144XG6 */
+	SWITCHTEC_PCI_DEVICE(0x6360, SWITCHTEC_GEN6),  /* PSX 160XG6 */
 	SWITCHTEC_PCI100X_DEVICE(0x1001, SWITCHTEC_GEN4),  /* PCI1001 16XG4 */
 	SWITCHTEC_PCI100X_DEVICE(0x1002, SWITCHTEC_GEN4),  /* PCI1002 12XG4 */
 	SWITCHTEC_PCI100X_DEVICE(0x1003, SWITCHTEC_GEN4),  /* PCI1003 16XG4 */
diff --git a/include/linux/switchtec.h b/include/linux/switchtec.h
index cdb58d61c1526..724da6c08bf7d 100644
--- a/include/linux/switchtec.h
+++ b/include/linux/switchtec.h
@@ -42,6 +42,7 @@ enum switchtec_gen {
 	SWITCHTEC_GEN3,
 	SWITCHTEC_GEN4,
 	SWITCHTEC_GEN5,
+	SWITCHTEC_GEN6,
 };
 
 struct mrpc_regs {
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-6.1] PCI: switchtec: Add Gen6 Device IDs

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing pci_free_irq_vectors() in error paths and driver teardown, leading to IRQ vector leaks.
--

commit 0bbab4b0d204e1f22ee16e8e7ffb4b1a30c43568
Author: Ben Reed <Ben.Reed@microchip.com>

PCI: switchtec: Add Gen6 Device IDs

Adds device IDs for the next generation of switchtec products. No changes
to the driver were required with the new version of the hardware.

Link: https://patch.msgid.link/20260505161633.67454-1-logang@deltatee.com

> diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
> index 5ff84fb8fb0f4..f32ddfa79da99 100644
> --- a/drivers/pci/switch/switchtec.c
> +++ b/drivers/pci/switch/switchtec.c

[ ... ]

[Severity: High]
This is a pre-existing issue, but while reviewing this driver for the
addition of these new device IDs, I noticed that IRQ vectors allocated
via pci_alloc_irq_vectors() do not appear to be freed in several error
paths and during driver teardown.

For example, in switchtec_init_isr(), there is an error path that
returns without freeing the previously allocated vectors:

drivers/pci/switch/switchtec.c:switchtec_init_isr() {
    ...
    if (event_irq < 0 || event_irq >= nvecs)
        return -EFAULT;
    ...
}

Similarly, during driver teardown, the remove function fails to call
pci_free_irq_vectors():

drivers/pci/switch/switchtec.c:switchtec_pci_remove() {
    struct switchtec_dev *stdev = pci_get_drvdata(pdev);
    ...
}

And the common exit function used for probe errors and driver unload
also omits the cleanup:

drivers/pci/switch/switchtec.c:switchtec_exit_pci() {
    if (stdev->dma_mrpc) {
        iowrite32(0, &stdev->mmio_mrpc->dma_en);
        flush_wc_buf(stdev);
        writeq(0, &stdev->mmio_mrpc->dma_addr);
        dma_free_coherent(&stdev->pdev->dev, sizeof(*stdev->dma_mrpc),
                          stdev->dma_mrpc, stdev->dma_mrpc_dma_addr);
        stdev->dma_mrpc = NULL;
    }
}

Does this code leak the IRQ vectors on unbind or when probing fails?
Should pci_free_irq_vectors() be called in these paths to prevent
exhausting system IRQ resources?

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

[PATCH AUTOSEL 6.18-5.10] PCI: mediatek: Protect root bus removal with rescan lock

[Sasha Levin]

From: Hans Zhang <18255117159@163.com>

[ Upstream commit a29812a55da8d0dbeb071b26ac428c338e3fc389 ]

Hold the pci_rescan_remove_lock lock while stopping and removing a root bus
to avoid racing with concurrent rescan or hotplug operations triggered via
sysfs.  Such races may lead to use-after-free issues or system crashes.

Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260521161822.132996-7-18255117159@163.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: `[PCI/mediatek]` `[Protect]` — Add missing
  `pci_rescan_remove_lock` around root bus teardown in
  `mtk_pcie_remove()`.

**Step 1.2 — Tags**
- Record:
  - `Signed-off-by`: Hans Zhang, Manivannan Sadhasivam, Bjorn Helgaas
  - `Link`:
    https://patch.msgid.link/20260521161822.132996-7-18255117159@163.com
  - No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Cc:
    stable@vger.kernel.org`
  - Notable: PCI subsystem maintainer (Bjorn Helgaas) committed it; part
    of a 9-patch series (patch 6/9)

**Step 1.3 — Body analysis**
- Record:
  - **Bug**: `mtk_pcie_remove()` calls `pci_stop_root_bus()` /
    `pci_remove_root_bus()` without `pci_rescan_remove_lock`, racing
    sysfs-triggered rescan/hotplug.
  - **Symptom**: Use-after-free or system crash.
  - **Root cause**: Missing synchronization with global PCI
    rescan/remove lock used by `pci-sysfs.c`.

**Step 1.4 — Hidden bug fix?**
- Record: No — explicitly described as a synchronization fix for a
  race/UAF.

---

## Phase 2: Diff Analysis

**Step 2.1 — Inventory**
- Record: 1 file (`drivers/pci/controller/pcie-mediatek.c`), +2 lines,
  function `mtk_pcie_remove()`. Single-file surgical fix.

**Step 2.2 — Code flow**
- Record:
  - **Before**: `pci_stop_root_bus()` → `pci_remove_root_bus()`
    unlocked.
  - **After**: `pci_lock_rescan_remove()` → stop/remove →
    `pci_unlock_rescan_remove()`.
  - Affects driver remove/unbind path only.

**Step 2.3 — Bug mechanism**
- Record: **Race condition / UAF**. Sysfs rescan/remove holds
  `pci_rescan_remove_lock`; driver remove did not. Concurrent teardown +
  rescan can walk freed PCI structures.

**Step 2.4 — Fix quality**
- Record: Obviously correct — matches `pci_host_common_remove()`, `pcie-
  mediatek-gen3` `mtk_pcie_remove()`, `pci-aardvark`, `pci-mvebu`.
  Minimal regression risk; standard mutex, no API change.

---

## Phase 3: Git History Investigation

**Step 3.1 — Blame**
- Record: `mtk_pcie_remove()` and unprotected
  `pci_stop/remove_root_bus()` from Honghui Zhang, Oct 2018
  (`031337ace2d1c2`). Bug present since driver introduction.

**Step 3.2 — Fixes: tag**
- Record: N/A — no `Fixes:` tag. Underlying gap: drivers added
  before/without adopting the lock pattern from commit `9d16947b75831`
  (Jan 2014).

**Step 3.3 — Related history**
- Record: Series merged on mainline as `7c97ee7c4951a` (9 driver fixes).
  Commit `a29812a55da8d` is the mediatek piece. Cover letter states each
  patch is independent. Similar unprotected callers remain in this tree
  (altera, rockchip, tegra, iproc, brcmstb, dwc, cadence, plda) —
  separate commits.

**Step 3.4 — Author context**
- Record: Hans Zhang; series reviewed/committed by Bjorn Helgaas;
  Manivannan Sadhasivam Signed-off-by on mediatek patch.

**Step 3.5 — Dependencies**
- Record: None. Requires only `pci_lock_rescan_remove()` /
  `pci_unlock_rescan_remove()` — present in this tree since
  `9d16947b75831`. `git apply --check` passes cleanly.

---

## Phase 4: Mailing List and External Research

**Step 4.1 — Discussion**
- Record: `b4 dig -c a29812a55da8d` →
  https://patch.msgid.link/20260521161822.132996-7-18255117159@163.com.
  v1 series, 9 patches. Bjorn Helgaas applied 8 patches and standardized
  commit logs. No NAKs.

**Step 4.2 — Reviewers**
- Record: `b4 dig -w` — CC'd Bjorn Helgaas, Lorenzo Pieralisi, Konrad
  Wilczynski, Manivannan Sadhasivam, Rob Herring, linux-pci@.

**Step 4.3 — Bug reports**
- Record: No user/syzbot report. sashiko-bot flagged the unprotected
  pattern as a race risk on the mediatek patch; separate pre-existing
  clock/PM issue noted (unrelated to this fix).

**Step 4.4 — Series context**
- Record: Patch 6/9; cover letter: "Each patch is independent and
  targets a specific controller driver."

**Step 4.5 — Stable list**
- Record: No `Cc: stable` in thread (expected; not a negative signal).

---

## Phase 5: Code Semantic Analysis

**Step 5.1 — Functions modified**
- Record: `mtk_pcie_remove()`.

**Step 5.2 — Callers**
- Record: Registered as `platform_driver.remove` for `mtk-pcie`; reached
  on device unbind, module unload, shutdown. `suppress_bind_attrs =
  true` limits sysfs bind/unbind, but module unload and platform device
  removal still invoke remove.

**Step 5.3 — Callees**
- Record: `pci_lock_rescan_remove()`, `pci_stop_root_bus()`,
  `pci_remove_root_bus()`, `pci_unlock_rescan_remove()`, then resource
  teardown.

**Step 5.4 — Reachability**
- Record: Race requires concurrent sysfs PCI rescan/remove (e.g.
  `/sys/bus/pci/rescan`, `.../rescan`, `.../remove`) while driver remove
  runs. Sysfs writes need elevated privileges; realistic under admin
  orchestration, firmware updates, or scripted hotplug.

**Step 5.5 — Similar patterns**
- Record: In this tree, `pcie-mediatek-gen3.c`, `pci-host-common.c`,
  `pci-aardvark.c`, `pci-mvebu.c`, `pci-hyperv.c` already use the lock.
  `pcie-mediatek.c` is the outlier among MediaTek drivers.

---

## Phase 6: Cross-Reference Against Local Tree (v6.18.44)

**Step 6.1 — Buggy code present?**
- Record: **Yes.** Tree is `v6.18.44` (`make kernelversion` = 6.18.44).
  `mtk_pcie_remove()` at lines 1157–1158 calls stop/remove without lock.
  Commit `a29812a55da8d` is **not** in HEAD (`merge-base --is-ancestor`
  exit 1).

**Step 6.2 — Backport complications**
- Record: Clean apply verified (`git apply --check` success). No
  structural conflicts.

**Step 6.3 — Related fixes already present?**
- Record: `git log HEAD --grep="Protect root bus removal"` — empty. Fix
  not yet in 6.18.y. Gen3 driver already has the lock from initial
  import.

---

## Phase 7: Subsystem Context

**Step 7.1 — Subsystem**
- Record: `drivers/pci/controller` — PCI host controller. **IMPORTANT**
  (core I/O path for affected SoCs).

**Step 7.2 — Activity**
- Record: Active maintenance (MSI, IRQ domain, refcount fixes in
  2024–2026).

---

## Phase 8: Impact and Risk

**Step 8.1 — Who is affected**
- Record: `CONFIG_PCIE_MEDIATEK` on ARCH_MEDIATEK / ARCH_AIROHA —
  MT2701, MT7623, MT2712, MT7622, MT7629 (routers, embedded boards).

**Step 8.2 — Trigger**
- Record: Concurrent sysfs PCI rescan/remove during driver remove.
  Uncommon but plausible; requires privileged sysfs access.

**Step 8.3 — Failure severity**
- Record: UAF / kernel crash — **HIGH** (potential **CRITICAL** security
  impact if exploitable timing exists).

**Step 8.4 — Risk/benefit**
- Record: **Benefit HIGH** (prevents crash/UAF on real hardware). **Risk
  VERY LOW** (2-line, established pattern). Strong benefit/risk ratio.

---

## Phase 9: Final Synthesis

**Step 9.1 — Evidence**

*For:*
- Real race with documented UAF/crash consequences
- PCI maintainer-reviewed fix
- Minimal, obviously correct, applies cleanly
- Infrastructure (`pci_lock_rescan_remove`) present since 2014 in this
  tree
- Bug in tree since 2018; gen3 sibling driver already uses the pattern
- Standalone — no series dependencies

*Against:*
- No syzbot/user crash report (theoretical until triggered)
- Privileged trigger for sysfs side of race
- Other PCI controllers in this tree have the same gap (scope beyond
  this commit, not a reason to reject this one)

**Step 9.2 — Stable rules checklist**
1. Obviously correct and tested? **PASS** — pattern used elsewhere;
   maintainer committed
2. Fixes real bug? **PASS** — verified race with sysfs lock mismatch
3. Important issue? **PASS** — UAF/crash
4. Small and contained? **PASS** — 2 lines, 1 file
5. No new features/APIs? **PASS**
6. Can apply to local tree? **PASS** — clean apply verified

**Step 9.3 — Exception category**
- Record: N/A (standard bug fix, not quirk/DT/build/doc exception)

**Step 9.4 — Decision rationale**
This commit closes a long-standing synchronization gap in the MediaTek
PCIe host driver on the v6.18.44 stable tree. The missing lock allows
root bus teardown to race sysfs rescan/remove operations that correctly
hold `pci_rescan_remove_lock`, with UAF/crash as the stated and credible
outcome. The fix is minimal, matches existing in-tree patterns
(including `pcie-mediatek-gen3.c`), has no dependencies, and applies
cleanly.

---

## Verification

- [Phase 1] Parsed subject, tags, body from commit `a29812a55da8d`
- [Phase 2] Diff: +2 lines wrapping stop/remove in `mtk_pcie_remove()`
- [Phase 3] `git blame`: buggy remove path from 2018 (`031337ace2d1c2`)
- [Phase 3] `git show 9d16947b75831`: `pci_lock_rescan_remove()` added
  2014; in this tree
- [Phase 3] `git merge-base --is-ancestor a29812a55da8d HEAD` → exit 1
  (not in tree)
- [Phase 3] `git apply --check` on commit diff → success
- [Phase 4] `b4 dig -c a29812a55da8d` → lore URL found
- [Phase 4] `b4 dig -a` → v1, patch 6/9
- [Phase 4] `b4 dig -w` → PCI maintainers CC'd
- [Phase 4] Mbox: Bjorn Helgaas review, no NAKs, no stable nomination
- [Phase 5] Read `pci-sysfs.c`: rescan/remove paths use
  `pci_lock_rescan_remove()`
- [Phase 5] Read `remove.c`: `pci_stop_and_remove_bus_device()` asserts
  lock held
- [Phase 5] Grep: gen3/aardvark/mvebu/host-common have lock; mediatek.c
  does not
- [Phase 6] `git describe HEAD` → v6.18.44; Makefile → 6.18.44
- [Phase 6] Read `pcie-mediatek.c` lines 1152–1164: unprotected
  stop/remove confirmed
- [Phase 8] Kconfig: `PCIE_MEDIATEK` on ARCH_MEDIATEK/AIROHA

**YES**The background searches finished and match the earlier analysis:

- **`pci_lock_rescan_remove()`** is already in this **v6.18.44** tree
  (from `9d16947b75831`, 2014), along with related ACPI/hotplug locking
  commits.
- A grep for **"Protect root bus removal"** on HEAD returned nothing —
  that fix series is not in this stable tree yet.
- The **MediaTek** patch still applies cleanly and remains a **YES** for
  backport: it adds the missing lock around `mtk_pcie_remove()` to
  prevent a race with sysfs PCI rescan/remove that can cause
  UAF/crashes.

 drivers/pci/controller/pcie-mediatek.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 6afce031523bd..ce2a3e04a953e 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -1154,8 +1154,10 @@ static void mtk_pcie_remove(struct platform_device *pdev)
 	struct mtk_pcie *pcie = platform_get_drvdata(pdev);
 	struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
 
+	pci_lock_rescan_remove();
 	pci_stop_root_bus(host->bus);
 	pci_remove_root_bus(host->bus);
+	pci_unlock_rescan_remove();
 	mtk_pcie_free_resources(pcie);
 
 	mtk_pcie_irq_teardown(pcie);
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] PCI: mediatek: Protect root bus removal with rescan lock

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing IRQ teardown in multiple error paths (probe, port enablement, resume) leading to memory leaks of IRQ domains and a critical Use-After-Free of `mtk_pcie_port`.
--

commit fb803b3fa12664e554b8c9a2ac4cd9f5ed0a4f0d
Author: Hans Zhang <18255117159@163.com>

PCI: mediatek: Protect root bus removal with rescan lock

This commit wraps pci_stop_root_bus() and pci_remove_root_bus() in
pci_lock_rescan_remove() to prevent race conditions during sysfs rescan or
hotplug operations.

Link: https://patch.msgid.link/20260521161822.132996-7-18255117159@163.com

> diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> index 24cc30a2ab6c6..e8af54efec9d6 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -1128,8 +1128,10 @@ static void mtk_pcie_remove(struct platform_device *pdev)
>  	struct mtk_pcie *pcie = platform_get_drvdata(pdev);
>  	struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
>  
> +	pci_lock_rescan_remove();
>  	pci_stop_root_bus(host->bus);
>  	pci_remove_root_bus(host->bus);
> +	pci_unlock_rescan_remove();
>  	mtk_pcie_free_resources(pcie);
>  
>  	mtk_pcie_irq_teardown(pcie);

[Severity: High]
This is a pre-existing issue, but since this teardown path correctly cleans
up IRQs, could other error paths be leaking IRQ domains or risking a
use-after-free by missing this teardown?

For instance, if mtk_pcie_enable_port() fails link training, it frees the
port memory:

drivers/pci/controller/pcie-mediatek.c:mtk_pcie_enable_port() {
    ...
err_sys_clk:
    mtk_pcie_port_free(port);
    ...
}

Does this leave the previously registered IRQ domains and chained handlers
active, potentially pointing to the freed port memory?

Similarly, on system resume, if a port fails to come up:

drivers/pci/controller/pcie-mediatek.c:mtk_pcie_resume_noirq() {
    ...
    list_for_each_entry_safe(port, tmp, &pcie->ports, list)
        mtk_pcie_enable_port(port);
    ...
}

Could this trigger a use-after-free when the chained handler accesses the
freed mtk_pcie_port structure?

There also seem to be similar missed cleanups during probe. If
mtk_pcie_probe() fails later on:

drivers/pci/controller/pcie-mediatek.c:mtk_pcie_probe() {
    ...
put_resources:
    if (!list_empty(&pcie->ports))
        mtk_pcie_put_resources(pcie);

    return err;
}

Will this free the port structures without tearing down the active chained
IRQ handler?

Also, if mtk_pcie_setup() fails midway during probe:

drivers/pci/controller/pcie-mediatek.c:mtk_pcie_probe() {
    ...
    err = mtk_pcie_setup(pcie);
    if (err)
        return err;
    ...
}

Could this leak the IRQ domains for successfully parsed ports, leaving
chained handlers pointing to devres-freed ports?

Finally, could domains be orphaned if IRQ setup or MSI allocation fails?

drivers/pci/controller/pcie-mediatek.c:mtk_pcie_setup_irq() {
    ...
    if (port->irq < 0)
        return port->irq;
    ...
}

And in mtk_pcie_init_irq_domain():

drivers/pci/controller/pcie-mediatek.c:mtk_pcie_init_irq_domain() {
    ...
    if (IS_ENABLED(CONFIG_PCI_MSI)) {
        ret = mtk_pcie_allocate_msi_domains(port);
        if (ret)
            return ret;
    }
    ...
}

Should these error paths be freeing port->irq_domain and other resources
created earlier?

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

[PATCH AUTOSEL 6.18] PCI: cadence: Protect root bus removal with rescan lock

[Sasha Levin]

From: Hans Zhang <18255117159@163.com>

[ Upstream commit 713331969ce89489c84af917058df6d9910cff97 ]

Hold the pci_rescan_remove_lock lock while stopping and removing a root bus
to avoid racing with concurrent rescan or hotplug operations triggered via
sysfs.  Such races may lead to use-after-free issues or system crashes.

Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260521161822.132996-2-18255117159@163.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:** `[PCI: cadence] [Protect] Root bus removal must hold the
global PCI rescan/remove mutex during teardown.`

### Step 1.2: Commit message tags
**Record:**
- **Fixes:** none
- **Reported-by:** none
- **Tested-by:** none
- **Reviewed-by:** none (in commit message; cover letter references
  sashiko-bot review)
- **Acked-by:** none
- **Link:**
  https://patch.msgid.link/20260521161822.132996-2-18255117159@163.com
- **Cc: stable:** none
- **Signed-off-by:** Hans Zhang, Manivannan Sadhasivam, Bjorn Helgaas
  (ignore pipeline-added SOBs)

Notable: no syzbot/user crash report; motivation comes from code review
and subsystem locking rules.

### Step 1.3: Commit body analysis
**Record:**
- **Bug:** `cdns_pcie_host_disable()` calls `pci_stop_root_bus()` /
  `pci_remove_root_bus()` without `pci_rescan_remove_lock`.
- **Symptom:** Race with concurrent sysfs PCI rescan or hotplug/remove;
  author cites possible UAF or system crash.
- **Root cause:** Root-bus teardown is not serialized with sysfs-driven
  rescan/remove paths that take the same lock.
- **Version info:** none in commit message.

### Step 1.4: Hidden bug fix detection
**Record:** Yes. Despite “Protect” rather than “fix”, this is a
synchronization bug fix, not cleanup or a feature. It matches the
established pattern used elsewhere in PCI host drivers.

---

## Phase 2: Diff Analysis

### Step 2.1: Change inventory
**Record:**
- **Files:** `drivers/pci/controller/cadence/pcie-cadence-host.c` (+2
  lines)
- **Function:** `cdns_pcie_host_disable()`
- **Scope:** Single-file, surgical fix (2 lines)

### Step 2.2: Code flow change
**Record:**
- **Before:** `pci_stop_root_bus()` → `pci_remove_root_bus()` with no
  lock.
- **After:** `pci_lock_rescan_remove()` wraps those calls, then
  `pci_unlock_rescan_remove()`.
- **Path:** Driver teardown / module unload (`j721e_pcie_remove()`,
  `sg2042_pcie_remove()`).

### Step 2.3: Bug mechanism
**Record:**
- **Category:** Race condition / missing synchronization.
- **Mechanism:** Sysfs rescan/remove holds `pci_rescan_remove_lock` (see
  `rescan_store`, `dev_rescan_store`, `remove_store` in `pci-sysfs.c`).
  Cadence host disable did not, so teardown could interleave with sysfs
  operations on the same bus hierarchy.

### Step 2.4: Fix quality
**Record:**
- **Quality:** High. Matches `pci_host_common_remove()` and
  `mtk_pcie_remove()`.
- **Regression risk:** Very low. Standard mutex already used across PCI
  core and many host drivers.
- **Red flags:** None.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:**
- Unlocked `pci_stop_root_bus()` / `pci_remove_root_bus()` introduced in
  **47f25da6c5ea5** (“PCI: cadence-host: Introduce
  cdns_pcie_host_disable() helper for cleanup”, 2025-04-17).
- Present in this tree (6.18.44).

### Step 3.2: Fixes: tag
**Record:** N/A — no `Fixes:` tag. Bug introduced by 47f25da6c5ea5 when
the helper was added without the lock.

### Step 3.3: Related file history
**Record:**
- **47f25da6c5ea5:** introduced `cdns_pcie_host_disable()`.
- **a2790bf81f0f7:** J721E module support uses the helper on remove.
- **1c72774df0284:** SG2042 driver uses it on remove.
- **1d59d474e1cb7:** probe-side rescan-lock fix with real crash trace
  (related pattern).
- **60e7b5aa85712:** lockdep assert added because this lock is required
  for removal paths.
- Fix commit is **not** merged in this tree yet.

### Step 3.4: Author context
**Record:** Hans Zhang has recent PCI controller patches. Mani
Sadhasivam and Bjorn Helgaas are PCI maintainers. Patch is part of a
9-patch series; cover letter says each patch is independent.

### Step 3.5: Dependencies
**Record:** None.
- `pci_lock_rescan_remove()` / `pci_unlock_rescan_remove()` exist and
  are exported.
- `cdns_pcie_host_disable()` exists in this tree.
- `pcie-cadence.h` includes `<linux/pci.h>`.
- Standalone backport.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original discussion
**Record:**
- Local mbox/cover: `20260522_18255117159_pci_controller_add_missing_res
  can_lock_around_root_bus_removal.{cover,mbx}`
- Series: **[PATCH 1/9]** for cadence; 9 independent controller-driver
  fixes.
- Cover cites sashiko-bot review asking whether unlocked teardown can
  race.
- `b4 dig` on HEAD did not match this commit (not merged yet).
- lore.kernel.org fetch returned 403 from this environment.

### Step 4.2: Reviewers
**Record:** Cover references sashiko-bot review thread. No explicit
maintainer stable nomination found in local mbox. Signed-off-by includes
PCI maintainers.

### Step 4.3: Bug report
**Record:** No user crash report or syzbot link for cadence
specifically. Precedent: **1d59d474e1cb7** documents a real NULL-deref
crash from the same class of race on the probe/add side.

### Step 4.4: Related patches
**Record:** 8 sibling patches for dwc, altera, brcmstb, iproc, mediatek,
rockchip, vmd, plda. Independent; cadence patch does not require them.

### Step 4.5: Stable list
**Record:** No stable-list discussion found (lore inaccessible; local
mbox has no `Cc: stable`).

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key functions
**Record:** `cdns_pcie_host_disable()` modified.

### Step 5.2: Callers
**Record:**
- `sg2042_pcie_remove()` — platform driver `.remove`
- `j721e_pcie_remove()` — platform driver `.remove` (RC mode)

Both run on driver unbind/module unload; can overlap with root-
privileged sysfs PCI operations.

### Step 5.3: Callees
**Record:** `pci_host_bridge_from_priv()`, `pci_stop_root_bus()`,
`pci_remove_root_bus()`, then `cdns_pcie_host_deinit()`,
`cdns_pcie_host_link_disable()`.

### Step 5.4: Reachability
**Record:**
- Trigger: driver remove/unbind while another context does sysfs
  `rescan` or `remove` on the same PCI hierarchy.
- Sysfs paths are root-accessible; concurrent admin activity during
  driver unload is realistic on embedded systems using Cadence PCIe (TI
  J721E, Sophgo SG2042).

### Step 5.5: Similar patterns
**Record:** Correct pattern already used in:
- `pci_host_common_remove()` (`pci-host-common.c:105-108`)
- `mtk_pcie_remove()` (`pcie-mediatek-gen3.c:1222-1225`)
- Many hotplug/EEH paths

Cadence was an outlier missing the lock.

---

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

### Step 6.1: Buggy code present?
**Record:** **Yes.** Current `cdns_pcie_host_disable()` at lines 618-628
in `pcie-cadence-host.c` lacks the lock. Tree: **v6.18.44** (`git
describe HEAD` → `v6.18.44-1-g2736c32da98b9`).

### Step 6.2: Backport complications
**Record:** Clean apply expected — 2-line addition in one function. No
conflicting changes seen.

### Step 6.3: Related fixes already present?
**Record:** Probe-side lock fix (1d59d474e1cb7) and lockdep assert
(60e7b5aa85712) are in tree. Cadence removal-side fix is **not**.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem criticality
**Record:** `drivers/pci/controller/cadence` — **IMPORTANT** (PCI host
controller). Affects embedded platforms with Cadence PCIe RC (J721E,
SG2042, etc.), not universal desktop paths.

### Step 7.2: Subsystem activity
**Record:** Active — recent cadence commits (module support, SG2042,
capability search, ops checks).

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who is affected
**Record:** Users of Cadence PCIe host controller drivers built as
modules or unbound during runtime, especially J721E and SG2042
platforms.

### Step 8.2: Trigger conditions
**Record:**
- Concurrent sysfs PCI rescan/remove and host driver teardown.
- Uncommon but plausible under admin automation or test scripts.
- Root can trigger sysfs paths; unprivileged users cannot directly, but
  crashes affect the whole system.

### Step 8.3: Failure mode severity
**Record:** UAF / kernel crash — **HIGH** (potential **CRITICAL** if
exploited or during production teardown). No cadence-specific crash log,
but PCI core documents this lock requirement and a similar race already
produced a crash on the add path.

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** Medium-high for affected platforms; prevents a known
  class of PCI race.
- **Risk:** Very low — 2 lines, established pattern.
- **Ratio:** Favorable for backport.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence summary

**FOR backport:**
- Real missing synchronization on PCI root-bus removal.
- Matches documented PCI locking rules and peer drivers.
- Small, obviously correct, standalone.
- Buggy code exists in 6.18.44 since 47f25da6c5ea5.
- Same subsystem already fixed probe-side race with documented crash
  (1d59d474e1cb7).
- lockdep enforcement (60e7b5aa85712) shows maintainers treat this lock
  as mandatory.

**AGAINST backport:**
- No concrete crash report for cadence specifically.
- Race needs concurrent sysfs activity during driver remove.
- Exposure window starts only from April 2025 when
  `cdns_pcie_host_disable()` was added.

**Unresolved:**
- Full lore review thread not readable here (403).
- No Tested-by on the patch itself.

The unresolved items are not enough to override the clear
synchronization defect.

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — matches existing PCI
   patterns; no Tested-by.
2. Fixes a real bug? **PASS** — missing lock on documented-required
   path.
3. Important issue? **PASS** — race can cause UAF/crash (HIGH).
4. Small and contained? **PASS** — 2 lines, one function.
5. No new features/APIs? **PASS**.
6. Can apply to local tree? **PASS** — prerequisites present; clean
   apply expected.

### Step 9.3: Exception categories
**Record:** None (not quirk/DT/build/docs). Standard bug-fix
synchronization.

### Step 9.4: Decision rationale

For **linux-6.18.y** (this checkout), `cdns_pcie_host_disable()`
performs root-bus teardown without `pci_rescan_remove_lock`, while sysfs
rescan/remove and many other PCI paths hold that lock. That is a real
race with crash/UAF potential, introduced when the helper was added in
47f25da6c5ea5. The fix is minimal, follows `pci_host_common_remove()`
and other host drivers, and needs no dependencies. PCI maintainers have
already treated this lock as mandatory elsewhere in the subsystem.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body from user-provided commit
  message and local mbox.
- **[Phase 1]** Read cover letter in `20260522_18255117159_pci_controlle
  r_add_missing_rescan_lock_around_root_bus_removal.cover`.
- **[Phase 2]** Confirmed diff: +2 lines around `pci_stop_root_bus()` /
  `pci_remove_root_bus()` in `cdns_pcie_host_disable()`.
- **[Phase 2]** Read current `cdns_pcie_host_disable()` at lines 618-628
  — no lock present.
- **[Phase 3]** `git describe HEAD` → v6.18.44; Makefile
  VERSION/PATCHLEVEL/SUBLEVEL = 6.18.44.
- **[Phase 3]** `git blame -L 618,628` → 47f25da6c5ea5 introduced
  unlocked removal.
- **[Phase 3]** `git merge-base --is-ancestor 47f25da6c5ea5 HEAD` →
  ancestor confirmed.
- **[Phase 3]** `git show 1d59d474e1cb7` → probe-side rescan lock fix
  with crash trace.
- **[Phase 3]** `git show 60e7b5aa85712` → lockdep assert on removal
  paths.
- **[Phase 3]** `git log --oneline -S cdns_pcie_host_disable` → callers
  in j721e/sg2042.
- **[Phase 4]** Read local mbox patch 1/9; series is 9 independent
  patches.
- **[Phase 4]** `b4 dig -c HEAD` — no match (commit not merged).
- **[Phase 4]** lore.kernel.org curl — 403 Forbidden (discussion not
  fully verified online).
- **[Phase 5]** Grep callers: `pci-j721e.c:670`, `pcie-sg2042.c:80`.
- **[Phase 5]** Read `pci-sysfs.c` rescan/remove stores — they take
  `pci_lock_rescan_remove()`.
- **[Phase 5]** Read `pci_host_common_remove()` and `mtk_pcie_remove()`
  — correct locking pattern.
- **[Phase 5]** Read `probe.c:3536-3552` — documents mutex requirement
  for rescan/removal.
- **[Phase 6]** Buggy code confirmed present; fix not merged (`git log
  --grep="Protect root bus removal"` — empty).
- **[Phase 6]** `pcie-cadence.h` includes `<linux/pci.h>` — lock APIs
  available.
- **UNVERIFIED:** Whether any production system has hit this specific
  cadence crash (no report found).

**YES**The analysis is done for **linux-6.18.y** (`v6.18.44`).

**Verdict: YES** — backport this commit.

`cdns_pcie_host_disable()` tears down the root bus without
`pci_rescan_remove_lock`, while sysfs rescan/remove and other PCI paths
use that lock. That can race on driver remove/unbind (J721E, SG2042) and
lead to crashes or use-after-free. The fix is two lines, matches
patterns like `pci_host_common_remove()`, and applies cleanly here; the
buggy path has been present since `cdns_pcie_host_disable()` was added
in 47f25da6c5ea5.

 drivers/pci/controller/cadence/pcie-cadence-host.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c b/drivers/pci/controller/cadence/pcie-cadence-host.c
index fffd63d6665e8..c8daa5847c0f3 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-host.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
@@ -620,8 +620,10 @@ void cdns_pcie_host_disable(struct cdns_pcie_rc *rc)
 	struct pci_host_bridge *bridge;
 
 	bridge = pci_host_bridge_from_priv(rc);
+	pci_lock_rescan_remove();
 	pci_stop_root_bus(bridge->bus);
 	pci_remove_root_bus(bridge->bus);
+	pci_unlock_rescan_remove();
 
 	cdns_pcie_host_deinit(rc);
 	cdns_pcie_host_link_disable(rc);
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18] PCI: cadence: Protect root bus removal with rescan lock

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Medium] Missing cleanup of host init and link setup on pci_host_probe failure.
- [Medium] Double pm_runtime_disable() due to mixing devm_pm_runtime_enable() and manual pm_runtime_disable().
--

commit 9d7375f353a2f9bf3cd5f3ff9c612cd84f44e32f
Author: Hans Zhang <18255117159@163.com>

PCI: cadence: Protect root bus removal with rescan lock
    
Hold the pci_rescan_remove_lock lock while stopping and removing a root bus
to avoid racing with concurrent rescan or hotplug operations triggered via
sysfs.

Link: https://patch.msgid.link/20260521161822.132996-2-18255117159@163.com

> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c b/drivers/pci/controller/cadence/pcie-cadence-host.c
> index fffd63d6665e8..c8daa5847c0f3 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
> @@ -620,8 +620,10 @@ void cdns_pcie_host_disable(struct cdns_pcie_rc *rc)
>  	struct pci_host_bridge *bridge;
>  
>  	bridge = pci_host_bridge_from_priv(rc);
> +	pci_lock_rescan_remove();
>  	pci_stop_root_bus(bridge->bus);
>  	pci_remove_root_bus(bridge->bus);
> +	pci_unlock_rescan_remove();
>  
>  	cdns_pcie_host_deinit(rc);
>  	cdns_pcie_host_link_disable(rc);

[Severity: Medium]
This isn't a bug introduced by this patch, but does cdns_pcie_host_setup() leak
hardware resources if a failure occurs during the probe phase?

If probe fails in cdns_pcie_host_init() due to a resource conflict:

drivers/pci/controller/cadence/pcie-cadence-host.c:cdns_pcie_host_setup() {
...
	ret = cdns_pcie_host_init(rc);
	if (ret)
		return ret;

Can this return without calling cdns_pcie_host_link_disable() to undo the prior
link setup?

Similarly, if the failure happens later in the same function:

	return pci_host_probe(bridge);
}

Will this return the error code without undoing the setup performed by both
cdns_pcie_host_link_setup() and cdns_pcie_host_init()?

This could leave the PCIe link started and root port BARs configured,
potentially preventing a clean re-initialization on subsequent probe attempts.

[Severity: Medium]
This is also a pre-existing issue, but could the driver reload path in
pcie-sg2042.c leave runtime PM permanently disabled?

When sg2042_pcie_probe() initializes power management:

drivers/pci/controller/cadence/pcie-sg2042.c:sg2042_pcie_probe() {
...
	pm_runtime_no_callbacks(dev);
	devm_pm_runtime_enable(dev);

This automatically registers a devres cleanup function to call
pm_runtime_disable() on driver unbind.

However, the remove function manually disables it again:

drivers/pci/controller/cadence/pcie-sg2042.c:sg2042_pcie_remove() {
...
	pm_runtime_disable(dev);
}

If an administrator unbinds and rebinds the driver, does this manual call
increment the disable_depth counter a second time alongside the devres cleanup?

On subsequent driver reprobe, devm_pm_runtime_enable() would only decrement
it by one, leaving disable_depth at 1. Would this prevent the device from
entering low-power states after a driver reload?

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

[PATCH AUTOSEL 6.18-5.15] ACPI: PCI: Clear _DEP dependencies after PCI root bridge attach

[Sasha Levin]

From: Chen Pei <cp0613@linux.alibaba.com>

[ Upstream commit 3a59c3b772e5dc0cedecce8e7fbf7c2d6245b643 ]

PCI root bridges enumerated by acpi_pci_root_add() can be the _DEP
supplier for other ACPI consumers, most notably ACPI0017 CXL root
devices whose probe path depends on acpi_pci_find_root() succeeding.
Once the root bus has been added, those consumers can safely be
enumerated, so notify them by clearing the dependency.

Call acpi_dev_clear_dependencies() at the end of acpi_pci_root_add(),
after pci_bus_add_devices(), following the same pattern used by other
ACPI suppliers such as the EC (drivers/acpi/ec.c) and the ACPI PCI
Link device (drivers/acpi/pci_link.c). The clear is intentionally
done only on the success path; on the error paths the supplier did
not attach and consumers must keep dep_unmet set.

This is a prerequisite for honoring _DEP on ACPI0016 host bridges,
which matters on architectures where the probe order of acpi_pci_root
relative to cxl_acpi is not guaranteed (e.g. RISC-V).

Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
Suggested-by: Dan Williams (nvidia) <djbw@kernel.org>
Tested-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Link: https://patch.msgid.link/20260526025118.38935-2-cp0613@linux.alibaba.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The background searches finished and match the earlier analysis:

- **Commit located**: `b52e0117014b6` (stable prep) and upstream
  `3a59c3b772e5d` — on `autosel` / `all-next`, not in current `v6.18.44`
  HEAD.
- **Companion patch**: `82dbacca5220e` (“Honor _DEP for ACPI0016”) is
  also only on `autosel`, not in 6.18.44.
- **Current tree**: `drivers/acpi/pci_root.c` still lacks
  `acpi_dev_clear_dependencies()`, and `acpi_honor_dep_ids[]` has no
  `ACPI0016` entry.

**Verdict unchanged: YES** — backport this commit together with patch
2/2 for the CXL `_DEP` ordering fix on 6.18.y.

 drivers/acpi/pci_root.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 74ade41603145..332568e00f37c 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -760,6 +760,10 @@ static int acpi_pci_root_add(struct acpi_device *device,
 	pci_lock_rescan_remove();
 	pci_bus_add_devices(root->bus);
 	pci_unlock_rescan_remove();
+
+	/* Clear _DEP dependencies to allow consumers to enumerate */
+	acpi_dev_clear_dependencies(device);
+
 	return 1;
 
 remove_dmar:
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.15] ACPI: PCI: Clear _DEP dependencies after PCI root bridge attach

[sashiko-bot]

> From: Chen Pei <cp0613@linux.alibaba.com>
> 
> [ Upstream commit 3a59c3b772e5dc0cedecce8e7fbf7c2d6245b643 ]
> 
> PCI root bridges enumerated by acpi_pci_root_add() can be the _DEP
> supplier for other ACPI consumers, most notably ACPI0017 CXL root
> devices whose probe path depends on acpi_pci_find_root() succeeding.
> Once the root bus has been added, those consumers can safely be
> enumerated, so notify them by clearing the dependency.
> 
> Call acpi_dev_clear_dependencies() at the end of acpi_pci_root_add(),
> after pci_bus_add_devices(), following the same pattern used by other
> ACPI suppliers such as the EC (drivers/acpi/ec.c) and the ACPI PCI
> Link device (drivers/acpi/pci_link.c). The clear is intentionally
> done only on the success path; on the error paths the supplier did
> not attach and consumers must keep dep_unmet set.
> 
> This is a prerequisite for honoring _DEP on ACPI0016 host bridges,
> which matters on architectures where the probe order of acpi_pci_root
> relative to cxl_acpi is not guaranteed (e.g. RISC-V).
> 
> Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
> Suggested-by: Dan Williams (nvidia) <djbw@kernel.org>
> Tested-by: Alison Schofield <alison.schofield@intel.com>
> Reviewed-by: Alison Schofield <alison.schofield@intel.com>
> Link: https://patch.msgid.link/20260526025118.38935-2-cp0613@linux.alibaba.com
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

[PATCH AUTOSEL 6.18-6.12] PCI/sysfs: Add CAP_SYS_ADMIN check to __resource_resize_store()

[Sasha Levin]

From: Krzysztof Wilczyński <kwilczynski@kernel.org>

[ Upstream commit 25ec7f57deceec633f27bc93b615f951e2ade814 ]

Currently, the __resource_resize_store() allows writing to the
resourceN_resize sysfs attribute to change a BAR's size without checking
for capabilities, currently relying only on the file access check.

Resizing a BAR modifies PCI device configuration and can disrupt active
drivers.  After the upcoming conversion to static attributes, it will also
trigger resource file updates via sysfs_update_groups().

Add a CAP_SYS_ADMIN check to prevent unprivileged users from performing BAR
resize operations.

Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://patch.msgid.link/20260508043543.217179-6-kwilczynski@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The background searches finished. Here’s what they turned up:

- **`b4 dig`** — Exited successfully but produced no output. The fix
  isn’t in this checkout, and `b4 dig` needs a commit hash, so the lore
  thread wasn’t resolved that way. Patch context came from the local v7
  mbox and Patchwork mirrors instead.
- **Git history (`resourceN_resize` / `__resource_resize_store`)** — In
  this shallow 6.18.43 tree, both only surface as merge commit
  `5d324e5159d9e`; the original introduction isn’t reachable here. The
  ABI doc (September 2022) is the best dating we have for when the sysfs
  interface landed.

That doesn’t change the earlier conclusion: the missing `CAP_SYS_ADMIN`
check is present in this tree, the fix is small and standalone, and the
backport recommendation remains **YES** for 6.18.y.

 drivers/pci/pci-sysfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index edb9bc34c0c58..990994db752ab 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1575,6 +1575,9 @@ static ssize_t __resource_resize_store(struct device *dev, int n,
 	int ret;
 	u16 cmd;
 
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
 	if (kstrtoul(buf, 0, &size) < 0)
 		return -EINVAL;
 
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] PCI/sysfs: Use kstrtobool() to parse the ROM attribute input

[Sasha Levin]

From: Krzysztof Wilczyński <kwilczynski@kernel.org>

[ Upstream commit 92742802ecbf215a2b60dcfd326d2213595010f1 ]

pci_write_rom() controls access to the ROM content through the
corresponding sysfs attribute, and treats the input as a request to
disable only when it matches the string "0\n" exactly:

  if ((off ==  0) && (*buf == '0') && (count == 2))

The count == 2 condition encodes the trailing newline that echo(1) appends.
This was found when userspace wrote "0" without a trailing newline aiming
to disable access, which failed to match the condition above and enabled
access instead.  For example:

  $ echo 0 > rom       # "0\n", count 2, access disabled
  $ echo -n 0 > rom    # "0", count 1, access enabled
  $ echo > rom         # "", count 1, access enabled (likely not desirable)

Parse the input with kstrtobool(), which handles common boolean inputs such
as "0", "1", "n", "y" or "off", "on", with or without a trailing newline,
so both of the above disable access, and update the now stale comment.

As a side effect, input that does not parse as a boolean is rejected with
-EINVAL rather than enabling access.  The documented "0" and "1" continue
to work as before, and rejecting malformed input brings the attribute in
line with how sysfs attributes typically handle it.

Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260612182448.552406-1-kwilczynski@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

### Step 1.1: Subject line
**Record:** `[PCI/sysfs] [use] Use kstrtobool() to parse the ROM
attribute input` — sysfs input-parsing fix in the PCI ROM bin_attribute
write path.

### Step 1.2: Tags
**Record:**
- **Link:** `https://patch.msgid.link/20260612182448.552406-1-
  kwilczynski@kernel.org`
- **Signed-off-by:** Krzysztof Wilczyński, Bjorn Helgaas (PCI
  maintainer)
- No Fixes:, Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, or Cc:
  stable

Notable: maintainer sign-off (Bjorn Helgaas), no fuzzer/user bug report
tags.

### Step 1.3: Body analysis
**Record:**
- **Bug:** `pci_write_rom()` only disables ROM sysfs access when input
  is exactly `"0\n"` (`count == 2`). `"0"` without newline (`count ==
  1`) is treated as enable.
- **Symptom:** `echo -n 0 > rom` enables access instead of disabling;
  empty write also enables.
- **Root cause:** Manual parsing tied disable to `count == 2` (echo’s
  trailing newline), not to boolean `"0"`.
- **Fix:** Use `kstrtobool()`; reject invalid input with `-EINVAL`.

### Step 1.4: Hidden bug fix?
**Record:** Yes — described as parsing improvement, but it fixes
inverted enable/disable semantics and undocumented dependence on a
trailing newline.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory
**Record:**
- **File:** `drivers/pci/pci-sysfs.c` (~+4/-3 net)
- **Function:** `pci_write_rom()`
- **Scope:** Single-file, surgical fix

### Step 2.2: Code flow
**Record:**
- **Before:** Disable only if `off==0 && *buf=='0' && count==2`;
  everything else enables.
- **After:** Parse with `kstrtobool()`; on failure return `-EINVAL`;
  otherwise set `pdev->rom_attr_enabled = enable`.
- **Path:** sysfs write to PCI `rom` bin_attribute (root-only, mode
  0600).

### Step 2.3: Bug mechanism
**Record:** **Logic/correctness fix** — fragile string/count check
instead of boolean parsing; violates documented “write 0 to disable”
semantics for writes without `\n`.

### Step 2.4: Fix quality
**Record:** Obviously correct, minimal, matches PCI sysfs patterns
(author’s 2021 kstrtobool series for other attrs). Low regression risk;
`kstrtobool()` only inspects `s[0]` (and `s[1]` for `on`/`off`), so it
is safe on sysfs buffers that may lack a trailing `NUL`.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:** Buggy `count == 2` logic dates to `1da177e4c3f41` (2005,
Linux 2.6.12-rc2). Present in this tree at lines 1319–1322.

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

### Step 3.3: Related history
**Record:** Related PCI sysfs work by same author merged earlier
(`36f354ec7bf92` EINVAL consistency, `95e83e219d689` CAP_SYS_ADMIN
checks). A 2021 series ([spinics
msg110641](https://www.spinics.net/lists/linux-pci/msg110641.html))
included this `pci_write_rom()` change but the ROM hunk was not merged
then; this 2026 commit is standalone.

### Step 3.4: Author context
**Record:** Krzysztof Wilczyński is an active PCI sysfs contributor;
Bjorn Helgaas signed off.

### Step 3.5: Dependencies
**Record:** None. `kstrtobool()` exists in `lib/kstrtox.c`; `bool` and
`rom_attr_enabled` exist in this tree. Applies standalone.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original discussion
**Record:** `b4 dig -c <sha>` failed (commit not in this checkout).
WebFetch of patch.msgid.link blocked (bot protection). Spinics 2021
series confirms intent and prior ROM fix that was not merged. No stable
nomination found in available threads.

### Step 4.2: Reviewers
**Record:** Bjorn Helgaas sign-off verified from commit message; 2021
series CC’d `linux-pci@`.

### Step 4.3: Bug report
**Record:** No external bug report or syzbot link; author discovered via
`echo -n 0` testing.

### Step 4.4: Series context
**Record:** Standalone 2026 commit; not part of an unmerged multi-patch
dependency chain.

### Step 4.5: Stable list
**Record:** No stable-list discussion found (WebSearch + blocked lore
fetch).

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key functions
**Record:** `pci_write_rom()`, `pci_read_rom()` (read path checks
`rom_attr_enabled`).

### Step 5.2: Callers
**Record:** `pci_write_rom` registered via `BIN_ATTR(rom, 0600,
pci_read_rom, pci_write_rom, 0)`; invoked from `sysfs_kf_bin_write()` on
root write to `/sys/bus/pci/devices/.../rom`.

### Step 5.3: Callees
**Record:** `kstrtobool()`, `to_pci_dev()`, sets
`pdev->rom_attr_enabled`.

### Step 5.4: Reachability
**Record:** Reachable by root (CAP_SYS_ADMIN) writing sysfs; documented
workflow: write `1` to enable ROM read, `0` to disable ([PCI sysfs
docs](https://www.kernel.org/doc/html/latest/PCI/sysfs-pci.html)).

### Step 5.5: Similar patterns
**Record:** `kstrtobool(buf, ...)` is standard in sysfs store handlers
across the tree; PCI sysfs already uses it elsewhere after the 2021
series.

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Buggy code present?
**Record:** **Yes.** Local tree is **6.18.44** (`git describe`:
`v6.18.44-1-g2736c32da98b9`). Buggy code at `drivers/pci/pci-
sysfs.c:1319-1322`. Fix not present (`git log -S 'kstrtobool(buf,
&enable)' -- drivers/pci/pci-sysfs.c` returned nothing).

### Step 6.2: Backport complications
**Record:** Clean apply expected — small hunk, no structural conflicts
observed.

### Step 6.3: Related fixes already present?
**Record:** No equivalent fix in this tree; EINVAL consistency work
exists but not for `pci_write_rom()`.

---

## Phase 7: Subsystem Context

### Step 7.1: Subsystem
**Record:** `drivers/pci` sysfs — **IMPORTANT** (core hardware
enumeration; affects all PCI platforms).

### Step 7.2: Activity
**Record:** Actively maintained; recent PCI sysfs commits in file
history.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who is affected
**Record:** Root/admin or tools writing to PCI `rom` sysfs without a
trailing newline (e.g. `echo -n 0`, `write(fd, "0", 1)`).

### Step 8.2: Trigger conditions
**Record:** Uncommon vs plain `echo 0`, but valid per kernel docs and
normal for programmatic sysfs clients. Root-only.

### Step 8.3: Failure mode severity
**Record:** **MEDIUM** — no crash/corruption, but inverted access-
control semantics: disable request enables ROM reads. Documented API
behavior is wrong for `"0"` without `\n`.

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** Correct boolean parsing; aligns with docs and other PCI
  sysfs attrs; rejects garbage with `-EINVAL`.
- **Risk:** Very low (~5 lines, established API).
- **Ratio:** Favorable for stable despite modest severity.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence summary

**FOR:**
- Real, reproducible logic bug (`echo -n 0` inverts intent)
- Violates documented “write 0 to disable” semantics
- Present since 2005 in this tree
- Tiny, maintainer-reviewed fix
- `kstrtobool()` already in tree
- Consistent with prior PCI sysfs input-validation work

**AGAINST:**
- No crash, deadlock, or data corruption
- Root-only sysfs (0600)
- Common `echo 0` path works
- No syzbot/user reports
- Borderline on stable “important issue” bar

**Unresolved:** Full lore thread for 20260612 patch (fetch blocked); no
explicit stable nomination found.

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — straightforward; maintainer
   SOB; no Tested-by.
2. Fixes a real bug? **PASS** — inverted enable/disable on valid input.
3. Important issue? **PASS (borderline)** — access-control semantics +
   documented API violation; not a crash fix.
4. Small and contained? **PASS**
5. No new features/APIs? **PASS** — behavior extension to
   `y`/`n`/`on`/`off` is minor and consistent with `kstrtobool()`
   elsewhere.
6. Can apply to local tree? **PASS**

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

### Step 9.4: Decision rationale
For **Linux 6.18.y**, the buggy code exists and the fix is absent. The
bug causes the opposite of the documented disable operation when `"0"`
is written without a newline — a longstanding sysfs correctness issue
with very low backport risk. That meets stable criteria, albeit at
modest severity.

---

## Verification

- [Phase 1] Parsed subject, tags, body from user-provided commit message
- [Phase 2] Read diff and current `pci_write_rom()` at `drivers/pci/pci-
  sysfs.c:1313-1325`
- [Phase 2] Read `pci_read_rom()` gate at lines 1347-1348
- [Phase 3] `git describe HEAD` → `v6.18.44-1-g2736c32da98b9`; Makefile
  → 6.18.44
- [Phase 3] `git blame -L 1302,1325 drivers/pci/pci-sysfs.c` → buggy
  logic from `1da177e4c3f41` (2005)
- [Phase 3] `git show 1da177e4c3f41:...` confirmed original `count == 2`
  logic
- [Phase 3] `git log -S 'kstrtobool(buf, &enable)' -- drivers/pci/pci-
  sysfs.c` → empty (fix not in tree)
- [Phase 3] `git log --author='Krzysztof Wilczyński' -- drivers/pci/pci-
  sysfs.c` → related EINVAL/CAP_SYS_ADMIN commits
- [Phase 4] `b4 dig` by commit hash → failed (commit not in checkout)
- [Phase 4] WebFetch patch.msgid.link → blocked by bot protection
- [Phase 4] WebFetch spinics msg110641 → 2021 series with same ROM fix
  (not merged then)
- [Phase 4] WebSearch → confirmed commit subject and merge context
- [Phase 5] Traced sysfs path via `fs/sysfs/file.c:150-168`
  (`sysfs_kf_bin_write`)
- [Phase 5] Read `kstrtobool()` at `lib/kstrtox.c:348-392` — only reads
  first 1–2 bytes
- [Phase 5] `grep kstrtobool(buf` in drivers → widespread sysfs pattern
- [Phase 6] Confirmed buggy code present, fix absent in 6.18.44 checkout
- [Phase 6] `grep rom_attr_enabled` → only `pci-sysfs.c` and
  `include/linux/pci.h`
- [Phase 8] Kernel PCI sysfs docs confirm write `"0"` to disable ROM
  access
- [Phase 8] `BIN_ATTR(rom, 0600, ...)` at line 1366 → root read/write
  only

**YES****Result:** For the checked-out **6.18.44** tree, this commit
should be backported.

`pci_write_rom()` only disables ROM sysfs access when the write is
exactly `"0\n"` (`count == 2`). Writing `"0"` without a newline (e.g.
`echo -n 0`) incorrectly **enables** access instead of disabling it,
which contradicts the documented “write 0 to disable” behavior. The fix
is small (switch to `kstrtobool()`), low risk, and the buggy code is
still present in this tree — the fix is not merged here yet.

 drivers/pci/pci-sysfs.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 990994db752ab..39e4a5b3e5739 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1308,18 +1308,19 @@ void __weak pci_remove_resource_files(struct pci_dev *dev) { return; }
  * @off: file offset
  * @count: number of byte in input
  *
- * writing anything except 0 enables it
+ * Writing a boolean value enables or disables the ROM display.
  */
 static ssize_t pci_write_rom(struct file *filp, struct kobject *kobj,
 			     const struct bin_attribute *bin_attr, char *buf,
 			     loff_t off, size_t count)
 {
 	struct pci_dev *pdev = to_pci_dev(kobj_to_dev(kobj));
+	bool enable;
 
-	if ((off ==  0) && (*buf == '0') && (count == 2))
-		pdev->rom_attr_enabled = 0;
-	else
-		pdev->rom_attr_enabled = 1;
+	if (kstrtobool(buf, &enable))
+		return -EINVAL;
+
+	pdev->rom_attr_enabled = enable;
 
 	return count;
 }
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] PCI/sysfs: Use kstrtobool() to parse the ROM attribute input

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unlocked read-modify-write of the `rom_attr_enabled` bitfield in `struct pci_dev` exposes a data race.
--

commit ede1ff2652bff89ab4ad252e8e7e79bb533b4702
Author: Krzysztof Wilczyński <kwilczynski@kernel.org>
PCI/sysfs: Use kstrtobool() to parse the ROM attribute input

This patch modifies pci_write_rom() to parse sysfs input using kstrtobool().
It ensures that the ROM attribute is properly disabled even when a trailing
newline is missing from the input, and it rejects invalid inputs with -EINVAL.

Link: https://patch.msgid.link/20260612182448.552406-1-kwilczynski@kernel.org

> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -1336,18 +1336,19 @@ void __weak pci_remove_resource_files(struct pci_dev *dev) { return; }
[ ... ]
>  static ssize_t pci_write_rom(struct file *filp, struct kobject *kobj,
>  			     const struct bin_attribute *bin_attr, char *buf,
>  			     loff_t off, size_t count)
>  {
>  	struct pci_dev *pdev = to_pci_dev(kobj_to_dev(kobj));
> +	bool enable;
>  
> -	if ((off ==  0) && (*buf == '0') && (count == 2))
> -		pdev->rom_attr_enabled = 0;
> -	else
> -		pdev->rom_attr_enabled = 1;
> +	if (kstrtobool(buf, &enable))
> +		return -EINVAL;
> +
> +	pdev->rom_attr_enabled = enable;

[Severity: High]
This is a pre-existing issue, but does this unlocked assignment expose a
data race?

In include/linux/pci.h, rom_attr_enabled is declared as a bitfield:

    struct pci_dev {
        ...
        unsigned int rom_attr_enabled:1;
        ...
    };

This bitfield shares a 32-bit machine word with other dynamically updated
fields like is_probed and irq_managed.

Since C bitfield assignments compile to non-atomic read-modify-write
operations on the underlying machine word, could a concurrent write to the
rom sysfs attribute race with updates to these other bitfields?

If a privileged user writes to the rom sysfs attribute concurrently with the
device being probed (where is_probed is toggled) or its IRQs being
configured, could this silently corrupt the word and result in deadlocks in
VF probing or IRQ resource leaks?

>  
>  	return count;
>  }

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

[PATCH AUTOSEL 6.18] PCI: dwc: Protect root bus removal with rescan lock

[Sasha Levin]

From: Hans Zhang <18255117159@163.com>

[ Upstream commit 26335696498ab502e907a556e97c7039bc80a87e ]

Hold the pci_rescan_remove_lock lock while stopping and removing a root bus
to avoid racing with concurrent rescan or hotplug operations triggered via
sysfs.  Such races may lead to use-after-free issues or system crashes.

Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260521161822.132996-3-18255117159@163.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
**Record:** `[PCI: dwc]` `[Protect]` — Add synchronization around root
bus teardown in the DesignWare PCIe host controller to prevent races
with concurrent PCI rescan/hotplug.

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
**Record:**
- **Link:**
  `https://patch.msgid.link/20260521161822.132996-3-18255117159@163.com`
- **Signed-off-by:** Hans Zhang `<18255117159@163.com>`
- **Signed-off-by:** Manivannan Sadhasivam `<mani@kernel.org>`
- **Signed-off-by:** Bjorn Helgaas `<bhelgaas@google.com>` (with
  `[bhelgaas: commit log]`)
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-
  by:`, or `Cc: stable@vger.kernel.org`
- Notable: PCI maintainer (Bjorn Helgaas) committed; DWC maintainer
  (Mani) signed off. No syzbot or user crash report in the message
  itself.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
**Record:**
- **Bug:** `dw_pcie_host_deinit()` stops and removes the root bus
  without holding `pci_rescan_remove_lock`.
- **Symptom:** Race with concurrent sysfs-triggered PCI rescan or
  hotplug; may cause use-after-free or system crashes.
- **Root cause:** `pci_stop_root_bus()` / `pci_remove_root_bus()` are
  not serialized against sysfs paths that already take
  `pci_lock_rescan_remove()`.
- **Version info:** None in the message.

### Step 1.4: DETECT HIDDEN BUG FIXES
**Record:** Not hidden — this is an explicit synchronization bug fix.
The “protect” wording and UAF/crash description clearly indicate a real
concurrency defect, not cleanup.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
**Record:**
- **Files:** `drivers/pci/controller/dwc/pcie-designware-host.c` (+2
  lines)
- **Function:** `dw_pcie_host_deinit()`
- **Scope:** Single-file, surgical fix (2 insertions around existing
  calls)

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Record:**
- **Hunk (deinit path):**
  - **Before:** `pci_stop_root_bus()` and `pci_remove_root_bus()` run
    unlocked during driver teardown.
  - **After:** Same operations run under `pci_lock_rescan_remove()` /
    `pci_unlock_rescan_remove()`.
  - **Path affected:** Platform driver remove / module unload / probe
    error cleanup via `dw_pcie_host_deinit()`.

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Record:**
- **Category:** Race condition / synchronization bug (can manifest as
  UAF or crash).
- **Mechanism:** Sysfs rescan/remove (`rescan_store`, `remove_store`,
  `bus_rescan_store` in `pci-sysfs.c`) holds `pci_rescan_remove_lock`.
  DWC host teardown did not, so two threads could concurrently mutate
  the same PCI bus/device tree.

### Step 2.4: ASSESS THE FIX QUALITY
**Record:**
- **Quality:** Obviously correct; matches the established pattern in
  `pci_host_common_remove()`, `pci-aardvark.c`, `pci-mvebu.c`, `pci-
  hyperv.c`, etc.
- **Regression risk:** Very low. The lock is a global PCI mutex already
  used widely; holding it only around bus stop/remove is the intended
  usage documented in `probe.c`.
- **Red flags:** None.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
**Record:**
- `pci_stop_root_bus()` / `pci_remove_root_bus()` in
  `dw_pcie_host_deinit()` introduced in commit `5808d43e7c91b2` (Rob
  Herring, Aug 2020).
- `dw_pcie_host_deinit()` itself dates to 2019.
- **Bug present since:** ~2020 in this function; DWC host code never had
  the rescan lock (`git log -S 'pci_lock_rescan_remove' -- pcie-
  designware-host.c` returned empty).

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

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
**Record:**
- Related fix in-tree: `1d59d474e1cb7` — “PCI: Hold rescan lock while
  adding devices during host probe” (Oct 2024), with a documented NULL
  deref crash from concurrent probe vs. sysfs remove.
- This commit is patch **2/9** in series “PCI: controller: Add missing
  rescan lock around root bus removal”; cover letter states **each patch
  is independent**.
- Fix is **not yet merged** in this tree (current `pcie-designware-
  host.c` still lacks the lock).

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
**Record:** Hans Zhang is an active PCI contributor (capability-search
refactors, cadence/dwc work). This series is a targeted locking fix, not
part of a larger refactor.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
**Record:**
- **Dependency:** `pci_lock_rescan_remove()` API from `9d16947b75831`
  (Jan 2014) — **present in this tree**.
- **Standalone:** Yes; no structural/API prerequisites beyond the
  existing lock helpers.
- Buggy code (`5808d43e7c91b2`) is also an ancestor of HEAD.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
**Record:**
- `b4 dig -c` failed (commit not in local history yet).
- Local mbox/cover files found: `20260522_18255117159_pci_controller_add
  _missing_rescan_lock_around_root_bus_removal.{cover,mbx}`.
- **Series:** 9 independent patches; this is patch 2/9 (DWC).
- **Cover letter context:** Bot review on a separate cadence patch
  flagged the same missing-lock pattern; author submitted this series to
  fix all affected controllers.
- **Lore URL fetch:** Blocked by Anubis anti-bot on lore.kernel.org.

### Step 4.2: CHECK WHO REVIEWED THE PATCH
**Record:** From commit message: Manivannan Sadhasivam (DWC maintainer)
SOB; Bjorn Helgaas (PCI maintainer) committed. `b4 dig -w` not available
for this unreleased commit.

### Step 4.3: SEARCH FOR THE BUG REPORT
**Record:** No `Reported-by:` or crash trace in this specific patch.
Precedent crash documented in `1d59d474e1cb7` for the **probe/add** side
of the same locking gap. This fix addresses the symmetric **remove**
side.

### Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
**Record:** 8 sibling patches fix the same pattern in cadence, altera,
brcmstb, iproc, mediatek, rockchip, vmd, plda. Each is independently
backportable.

### Step 4.5: CHECK STABLE MAILING LIST HISTORY
**Record:** Not searched (lore blocked). No stable-list discussion found
in local mbox files.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
**Record:** `dw_pcie_host_deinit()` — only function modified.

### Step 5.2: TRACE CALLERS
**Record:** `dw_pcie_host_deinit()` is called from multiple DWC-based
platform drivers:
- `pcie-tegra194.c` (`tegra_pcie_deinit_controller()` → platform
  `.remove` and probe error path)
- `pcie-stm32.c`, `pcie-rcar-gen4.c`, `pci-meson.c`, `pci-dra7xx.c`,
  `pcie-bt1.c`, `pci-exynos.c`, `pcie-kirin.c`, `pcie-intel-gw.c`
- **Context:** Driver remove, module unload, and probe failure cleanup
  on embedded/SoC platforms using Synopsys DWC PCIe.

### Step 5.3: TRACE CALLEES
**Record:** Key callees in the critical section:
- `pci_stop_root_bus()` — stops child devices, releases host bridge
  driver
- `pci_remove_root_bus()` — removes child devices, deletes host bridge
  from device model
- Both documented to require the rescan/remove lock when racing with
  sysfs operations.

### Step 5.4: FOLLOW THE CALL CHAIN
**Record:**
- **Trigger A:** Platform device remove / module rmmod →
  `dw_pcie_host_deinit()` → unlocked bus teardown.
- **Trigger B (concurrent):** Root/admin writes to
  `/sys/bus/pci/rescan`, `/sys/bus/pci/devices/.../remove`, or per-bus
  rescan sysfs → `pci_lock_rescan_remove()` → bus mutation.
- **Userspace reachability:** Sysfs PCI operations require privileges;
  race is realistic during driver unbind/rebind, hotplug, or admin
  tooling — not merely theoretical.

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
**Record:** In this tree, several controllers already protect removal
with the lock (`pci-host-common.c`, `pci-aardvark.c`, `pci-mvebu.c`,
`pcie-mediatek-gen3.c`, `pci-hyperv.c`). DWC and others listed in the
series do **not** — inconsistent, known-bad pattern.

---

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

### Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
**Record:**
- **Tree:** `v6.18.44` (`stable/linux-6.18.y`, detached HEAD at
  `2736c32da98b9`)
- **Buggy code:** **YES** — `pcie-designware-host.c:709-710` calls
  `pci_stop_root_bus()` / `pci_remove_root_bus()` without locking.
- **Bug age:** Present since ~2020; not a post-6.18 regression.

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
**Record:** **Clean apply expected** — 2-line addition with no context
conflicts. File has recent churn but the `dw_pcie_host_deinit()`
teardown block is stable and matches the patch hunk.

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
**Record:** Probe-side rescan lock fix (`1d59d474e1cb7`) is in-tree.
Remove-side DWC fix is **not** present. No duplicate fix found.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
**Record:** **PCI / DWC host controller drivers** — **IMPORTANT**.
Affects many ARM/embedded SoC platforms (Tegra, STM32, Kirin, Meson,
Exynos, R-Car, etc.), not universal but widely deployed.

### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
**Record:** PCI controller code is actively maintained; recent related
stable-worthy fix (`1d59d474e1cb7`) shows the subsystem maintainers
treat rescan-lock gaps as real crash bugs.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
**Record:** Users of DWC-based PCIe host controllers on platforms using
`dw_pcie_host_deinit()` — embedded ARM servers/devices, Tegra, various
SoCs. Config-dependent on `CONFIG_PCIE_DW_HOST` and specific platform
drivers.

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
**Record:**
- **Trigger:** Concurrent root bus removal (driver unload/remove) with
  sysfs PCI rescan/remove/hotplug.
- **Likelihood:** Uncommon but realistic during driver rebinding,
  development, or admin maintenance.
- **Unprivileged trigger:** No direct unprivileged sysfs access; race
  still matters for system stability under privileged operations.

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
**Record:**
- **Failure mode:** Use-after-free, NULL pointer dereference, kernel
  oops/crash during concurrent bus teardown.
- **Severity:** **CRITICAL** (system crash; potential memory
  corruption).

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
**Record:**
- **Benefit:** **High** — prevents crashes on a common PCIe IP block
  across many platforms; aligns DWC with already-fixed controllers.
- **Risk:** **Very low** — 2-line, established locking pattern, no
  API/behavior change beyond proper serialization.
- **Ratio:** Strong benefit, minimal risk.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Real race between bus removal and sysfs rescan/remove paths.
- Documented failure modes (UAF/crash) in commit message; strong
  precedent in `1d59d474e1cb7`.
- Tiny, obviously correct fix matching multiple in-tree controllers.
- Buggy code present in v6.18.44; prerequisites
  (`pci_lock_rescan_remove`) present.
- Standalone patch; maintainer-reviewed.
- Affects widely used DWC PCIe host path on many embedded platforms.

**AGAINST backporting:**
- No explicit user crash report or syzbot entry for this specific patch.
- Race requires concurrent privileged sysfs activity (somewhat
  uncommon).
- Part of a 9-patch series (though each patch is independent).

**UNRESOLVED:**
- Full lore.kernel.org review thread (blocked by anti-bot).
- No independent `Tested-by:` on this specific DWC patch.

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — pattern is standard;
   maintainer SOBs; no test report but fix is trivial and well-
   precedented.
2. Fixes a real bug? **PASS** — missing lock on a documented race path.
3. Important issue? **PASS** — UAF/kernel crash potential
   (**CRITICAL**).
4. Small and contained? **PASS** — 2 lines, one function.
5. No new features or APIs? **PASS** — uses existing lock API only.
6. Can apply to the local tree? **PASS** — buggy code and API both
   present; clean apply expected.

### Step 9.3: EXCEPTION CATEGORIES
**Record:** None (not a quirk/DT/build/docs fix). This is a core
synchronization bug fix.

### Step 9.4: DECISION RATIONALE

For **linux-6.18.y** (`v6.18.44`), `dw_pcie_host_deinit()` removes the
root PCI bus without the global rescan/remove lock that sysfs PCI
operations already use. That is the same class of defect already fixed
on the probe/add path (`1d59d474e1cb7`) and already handled correctly in
several other PCI host controller drivers in this tree. The fix is
minimal, self-contained, and prevents realistic kernel crashes during
driver teardown on DWC-based platforms.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body; no Fixes/Reported-by;
  maintainer SOBs present.
- **[Phase 2]** Confirmed diff: +2 lines wrapping
  `pci_stop/remove_root_bus` in `dw_pcie_host_deinit()`.
- **[Phase 3]** `git blame`: buggy calls from `5808d43e7c91b2` (2020);
  `git log -S`: DWC never had rescan lock.
- **[Phase 3]** `git merge-base --is-ancestor`: `9d16947b75831` YES,
  `5808d43e7c91b2` YES.
- **[Phase 3]** Related fix `1d59d474e1cb7` confirmed in tree with crash
  stack trace.
- **[Phase 3]** `git log --grep`: fix not merged in this tree.
- **[Phase 4]** Read local mbox/cover for series context; patch 2/9,
  independent patches stated.
- **[Phase 4]** `b4 dig -c`: failed (commit not in tree); lore fetch
  blocked.
- **[Phase 5]** `grep dw_pcie_host_deinit(`: 9 platform driver call
  sites verified.
- **[Phase 5]** Read `pci-sysfs.c`: rescan/remove paths use
  `pci_lock_rescan_remove()`.
- **[Phase 5]** Read `pci-host-common.c`, `probe.c`: lock pattern and
  API confirmed.
- **[Phase 5]** `grep pci_lock_rescan_remove` in
  `drivers/pci/controller/`: multiple drivers already protected; DWC
  not.
- **[Phase 6]** `git describe HEAD`: `v6.18.44-1-g2736c32da98b9`;
  `Makefile`: 6.18.44.
- **[Phase 6]** Read `pcie-designware-host.c:703-724`: buggy code
  confirmed present.
- **[Phase 8]** Traced `tegra_pcie_dw_remove` →
  `tegra_pcie_deinit_controller` → `dw_pcie_host_deinit`.

**YES**The analysis is complete: **backport this commit to
linux-6.18.y**.

`dw_pcie_host_deinit()` in `pcie-designware-host.c` removes the root PCI
bus without `pci_lock_rescan_remove()`, which can race with sysfs
rescan/remove and cause UAF or kernel crashes. The fix is two lines,
matches patterns already used in other PCI host drivers in this tree,
and applies cleanly to v6.18.44 where the bug is still present.

**YES**

 drivers/pci/controller/dwc/pcie-designware-host.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 48e4a887bb1bb..d5c24098c3dd3 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -706,8 +706,10 @@ void dw_pcie_host_deinit(struct dw_pcie_rp *pp)
 
 	dwc_pcie_debugfs_deinit(pci);
 
+	pci_lock_rescan_remove();
 	pci_stop_root_bus(pp->bridge->bus);
 	pci_remove_root_bus(pp->bridge->bus);
+	pci_unlock_rescan_remove();
 
 	dw_pcie_stop_link(pci);
 
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18] PCI: dwc: Protect root bus removal with rescan lock

[sashiko-bot]

> From: Hans Zhang <18255117159@163.com>
> 
> [ Upstream commit 26335696498ab502e907a556e97c7039bc80a87e ]
> 
> Hold the pci_rescan_remove_lock lock while stopping and removing a root bus
> to avoid racing with concurrent rescan or hotplug operations triggered via
> sysfs.  Such races may lead to use-after-free issues or system crashes.
> 
> Signed-off-by: Hans Zhang <18255117159@163.com>
> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
> [bhelgaas: commit log]
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Link: https://patch.msgid.link/20260521161822.132996-3-18255117159@163.com
> Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

[PATCH AUTOSEL 6.18-5.10] PCI: Stop setting cached power state to 'unknown' on unbind

[Sasha Levin]

From: Lukas Wunner <lukas@wunner.de>

[ Upstream commit d462c8e89e84bfb6417e6b4c88e0cb7cc747ba41 ]

When a PCI device is unbound from its driver, pci_device_remove() sets the
cached power state in pci_dev->current_state to PCI_UNKNOWN.  This was
introduced by commit 2449e06a5696 ("PCI: reset pci device state to unknown
state for resume") to invalidate the cached power state in case the system
is subsequently put to sleep.

For bound devices, the cached power state is set to PCI_UNKNOWN in
pci_pm_suspend_noirq(), immediately before entering system sleep.

Extend to unbound devices for consistency.

This obviates the need to change the cached power state on unbind, so stop
doing so.

Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/af7d11d3ceb231acc90829f7a5c8400c2446744f.1776415510.git.lukas@wunner.de
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:** `[PCI]` `[Stop]` — Stop setting cached power state to
`PCI_UNKNOWN` on driver unbind; move invalidation to the system-suspend
path for driverless devices.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Lukas Wunner `<lukas@wunner.de>` (author)
- **Signed-off-by:** Bjorn Helgaas `<bhelgaas@google.com>` (PCI
  maintainer)
- **Reviewed-by:** Mario Limonciello (AMD) `<superm1@kernel.org>`
- **Link:** https://patch.msgid.link/af7d11d3ceb231acc90829f7a5c8400c244
  6744f.1776415510.git.lukas@wunner.de
- **No** Fixes:, Reported-by:, Tested-by:, Cc: stable@vger.kernel.org,
  or syzbot tags
- Notable: PCI subsystem maintainer sign-off; AMD reviewer found no
  corner cases

### Step 1.3: Body Analysis
**Record:**
- **Bug described:** On driver unbind, `pci_device_remove()` sets
  `pci_dev->current_state = PCI_UNKNOWN` while hardware may still be in
  D0. Bound devices only invalidate the cache in
  `pci_pm_suspend_noirq()` right before sleep. Driverless/unbound
  devices on the `!pm` suspend path skipped that invalidation.
- **Symptom/failure mode:** Stale cached power state after
  suspend/resume can cause `pci_set_power_state(dev, PCI_D0)` to return
  early (believing the device is already in D0) when hardware is
  actually in D3 — the same class of failure as bugzilla #6024 fixed by
  commit 2449e06a5696.
- **Version info:** References 2449e06a5696 (2006); commit d462c8e89e84
  landed in mainline April 2026.
- **Root cause:** PCI_UNKNOWN invalidation was done at unbind time (too
  early) and was missing from the `!pm` branch of
  `pci_pm_suspend_noirq()`.

### Step 1.4: Hidden Bug Fix?
**Record:** Yes. Described as “consistency,” but it closes a real PM
correctness gap: driverless PCI devices on S2RAM suspend never had their
cached state invalidated, and prematurely setting UNKNOWN at unbind left
cache ≠ hardware between unbind and suspend.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory
**Record:**
- **File:** `drivers/pci/pci-driver.c` (+2 / −8 lines)
- **Functions:** `pci_device_remove()`, `pci_pm_suspend_noirq()`
- **Scope:** Single-file surgical fix

### Step 2.2: Code Flow Changes
**Record:**
- **Hunk 1 (`pci_device_remove`):** Before — set `PCI_UNKNOWN` on unbind
  if cached state was D0. After — remove that; cached state stays
  accurate while hardware is still D0.
- **Hunk 2 (`pci_pm_suspend_noirq`):** Before — `!pm` path
  (`pci_save_state` then `goto Fixup`) skipped
  `pci_pm_set_unknown_state()`. After — `goto set_unknown` ensures
  driverless devices also invalidate cache immediately before sleep,
  same as bound devices.

### Step 2.3: Bug Mechanism
**Record:** **Logic / correctness fix (PCI PM cache coherency).**
`pci_set_power_state()` early-returns when `dev->current_state == state`
(see `__pci_set_power_state()` at line 1545 in `pci.c`). Stale D0 after
BIOS changes hardware to D3 during suspend prevents powering the device
back up on driver bind — identical mechanism to bugzilla #6024.

### Step 2.4: Fix Quality
**Record:** Minimal, obviously correct, mirrors existing bound-device
behavior. Low regression risk: only moves UNKNOWN invalidation from
unbind to suspend_noirq; hibernate path (`pci_pm_freeze_noirq`) already
called `pci_pm_set_unknown_state()` for all devices.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:** Unbind-time `PCI_UNKNOWN` logic traces to 2449e06a5696
(“PCI: reset pci device state to unknown state for resume”, 2006). That
commit is present in this tree. `pci_pm_set_unknown_state()` exists at
line 606 in current `pci-driver.c`.

### Step 3.2: Fixes: Tag
**Record:** N/A — no Fixes: tag. Referenced commit 2449e06a5696 is in
this tree and introduced the unbind-time behavior this patch refines.

### Step 3.3: Related Changes
**Record:** Related recent fix: 382895a288515 “PCI/PM: Reinstate
clearing state_saved in legacy and !PM codepaths” (already in 6.18.43).
No patch-series dependency; standalone 1/1 commit (d462c8e89e84).

### Step 3.4: Author Context
**Record:** Lukas Wunner is a regular PCI/PM contributor. Bjorn Helgaas
(PCI maintainer) applied and signed off. No other related commits from
this author in the immediate `pci-driver.c` history of this tree.

### Step 3.5: Dependencies
**Record:** No prerequisites. Requires only existing
`pci_pm_set_unknown_state()` and `pci_pm_suspend_noirq()` `!pm` path —
all present in Linux 6.18.43. Patch applies cleanly (`git apply --check`
passed).

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Discussion
**Record:** b4 dig found thread at https://patch.msgid.link/af7d11d3ceb2
31acc90829f7a5c8400c2446744f.1776415510.git.lukas@wunner.de. Single v1
patch; Bjorn applied to `pci/pm`; Mario Limonciello Reviewed-by with no
corner cases found. No stable nomination or NAKs.

### Step 4.2: Reviewers
**Record:** b4 dig -w: To/Cc included Bjorn Helgaas, Rafael Wysocki,
Mario Limonciello, Alex Williamson, linux-pci@vger.kernel.org.

### Step 4.3: Bug Reports
**Record:** No new bug report. Commit references historical bugzilla
#6024 class via 2449e06a5696. No syzbot link.

### Step 4.4: Series Context
**Record:** Standalone patch, not part of a multi-patch series.

### Step 4.5: Stable List History
**Record:** lore.kernel.org blocked by bot protection; no stable-list
discussion found via b4 mbox thread.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** `pci_device_remove()`, `pci_pm_suspend_noirq()`,
`pci_pm_set_unknown_state()`, `pci_set_power_state()` /
`__pci_set_power_state()`.

### Step 5.2: Callers
**Record:** `pci_device_remove` — PCI bus `.remove` callback (sysfs
unbind, module unload). `pci_pm_suspend_noirq` — PCI bus
`.suspend_noirq` for every PCI device during system suspend.

### Step 5.3: Callees
**Record:** `pci_save_state()`, `pci_pm_set_unknown_state()`,
`pci_fixup_device()`, `pci_prepare_to_sleep()` (bound path only).

### Step 5.4: Reachability
**Record:** Any PCI device without a bound driver (or driver without PM
ops) going through system suspend hits the `!pm` path. Users can trigger
via S3/S2RAM; driver bind after resume via `modprobe` or sysfs is
common. Reachable without privileges for suspend; driver bind typically
requires root.

### Step 5.5: Similar Patterns
**Record:** `pci_pm_freeze_noirq()` already calls
`pci_pm_set_unknown_state()` unconditionally (line 1098). Suspend path
was inconsistent for driverless devices.

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Buggy Code Present?
**Record:** **Yes.** Tree is **Linux 6.18.43** (`git describe HEAD` →
v6.18.43). Buggy code confirmed at lines 497–498 (unbind UNKNOWN) and
line 874 (`goto Fixup` skipping `pci_pm_set_unknown_state` for `!pm`).

### Step 6.2: Backport Complications
**Record:** Patch applies cleanly with no modifications. No significant
refactoring conflicts in this area of 6.18.43.

### Step 6.3: Related Fixes Already Present?
**Record:** No equivalent fix in this tree. Commit d462c8e89e84 is not
in 6.18.43.

---

## Phase 7: Subsystem Context

### Step 7.1: Subsystem / Criticality
**Record:** **drivers/pci** — CORE subsystem. PCI PM affects virtually
all systems.

### Step 7.2: Activity
**Record:** Actively maintained; recent PM fix 382895a288515 already
backported to this tree.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Systems with PCI devices that are driverless at suspend time
(never probed, intentionally unbound, or drivers without PM ops) that
later get a driver bound after resume.

### Step 8.2: Trigger Conditions
**Record:** System suspend (S2RAM) → resume → driver bind. Uncommon but
realistic for manual sysfs bind/unbind workflows and devices without in-
tree drivers. Not security-relevant; requires suspend cycle.

### Step 8.3: Failure Mode Severity
**Record:** Device fails to power up / probe after resume (stale D0
cache). **Severity: MEDIUM-HIGH** for affected users (hardware non-
functional), but not a kernel crash, deadlock, or data corruption.

### Step 8.4: Risk-Benefit
**Record:** **Benefit:** MEDIUM — fixes latent PM bug for driverless
devices; improves cache accuracy between unbind and suspend. **Risk:**
VERY LOW — 10-line change, maintainer-reviewed, net deletion of code.
**Ratio:** Favorable.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Fixes real PCI PM cache bug for driverless devices on S2RAM suspend
  (same failure class as bugzilla #6024)
- Stops incorrect premature UNKNOWN at unbind while hardware is still D0
- Tiny, surgical, PCI maintainer + AMD reviewed
- Applies cleanly to 6.18.43
- Aligns suspend path with existing hibernate path behavior

**AGAINST backport:**
- No explicit user bug report or syzbot hit
- Failure is device malfunction, not kernel oops/panic
- Described primarily as “consistency” in commit message
- No stable nomination in review thread

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

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — minimal diff, maintainer-
   reviewed, corner-case review done
2. Fixes a real bug affecting users? **PASS** — stale power-state cache
   prevents device power-up after suspend+bind
3. Important issue? **PASS (moderate)** — device non-functionality after
   suspend, same class as historical PCI PM bug
4. Small and contained? **PASS** — 1 file, 10 lines
5. No new features or APIs? **PASS**
6. Can apply to local tree? **PASS** — verified clean apply

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

### Step 9.4: Problem Summary for Stable Users

This commit fixes a gap in PCI core suspend handling: devices without a
driver (or without PM callbacks) never had their cached power state
invalidated before sleep, while bound devices did. After suspend/resume,
if the BIOS changes the hardware power state, the kernel can believe the
device is still in D0 and skip the transition back to D0 when a driver
is later bound — leaving hardware dead. The patch also stops marking the
cache as UNKNOWN at unbind time when hardware is still in D0, deferring
invalidation to `pci_pm_suspend_noirq()` where bound devices already do
it.

For Linux 6.18.43, the buggy code is present, prerequisites exist, and
the patch applies cleanly with very low risk.

---

## Verification

- [Phase 1] Parsed subject, tags, body from provided commit message and
  kernel.org (d462c8e89e84)
- [Phase 1] Confirmed no Reported-by/syzbot/Fixes:/Cc: stable tags
- [Phase 2] Diff analysis: 2 insertions, 8 deletions in `pci-driver.c`;
  two functions modified
- [Phase 2] Read `__pci_set_power_state()` early-return at line 1545 in
  `pci.c`
- [Phase 3] `git describe HEAD` → v6.18.43; Makefile VERSION 6.18.43
- [Phase 3] `git show 2449e06a5696` — original unbind UNKNOWN logic and
  bugzilla #6024 context
- [Phase 3] `git blame` lines 493–498 — unbind UNKNOWN code present
- [Phase 3] Confirmed `pci_pm_set_unknown_state()` at line 606 in local
  tree
- [Phase 4] `b4 dig -c d462c8e89e84` — found lore thread URL
- [Phase 4] `b4 dig -w` — reviewers/maintainers CC'd
- [Phase 4] Downloaded mbox: Bjorn applied, Mario Reviewed-by, no stable
  nomination
- [Phase 4] lore.kernel.org direct fetch blocked (403/bot protection)
- [Phase 5] Traced `pci_pm_suspend_noirq` `!pm` → `goto Fixup` at line
  874 (buggy)
- [Phase 5] Confirmed `pci_pm_freeze_noirq` already sets UNKNOWN at line
  1098
- [Phase 6] Buggy code at lines 497–498 and 874 confirmed in 6.18.43
- [Phase 6] `git apply --check` on upstream patch — applies cleanly
- [Phase 6] Commit d462c8e89e84 not in 6.18.43 tree
- [Phase 8] Failure mode: stale D0 → device won't power up on driver
  bind; severity MEDIUM-HIGH for affected cases

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

- **Local tree (6.18.43):** The fix is **not** present. The buggy paths
  are still there — `PCI_UNKNOWN` is set on unbind, and the `!pm` branch
  in `pci_pm_suspend_noirq()` still skips `pci_pm_set_unknown_state()`.
- **Mainline (kernel.org):** The commit is **d462c8e89e84** (“PCI: Stop
  setting cached power state to 'unknown' on unbind”), merged April 27,
  2026 via the `pci/pm` branch.

That confirms the patch is a valid backport candidate for this tree and
applies cleanly. **Verdict remains YES.**

 drivers/pci/pci-driver.c | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index f9ead94d5ebb6..1219f39b1c69b 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -490,13 +490,6 @@ static void pci_device_remove(struct device *dev)
 	/* Undo the runtime PM settings in local_pci_probe() */
 	pm_runtime_put_sync(dev);
 
-	/*
-	 * If the device is still on, set the power state as "unknown",
-	 * since it might change by the next time we load the driver.
-	 */
-	if (pci_dev->current_state == PCI_D0)
-		pci_dev->current_state = PCI_UNKNOWN;
-
 	/*
 	 * We would love to complain here if pci_dev->is_enabled is set, that
 	 * the driver should have called pci_disable_device(), but the
@@ -871,7 +864,7 @@ static int pci_pm_suspend_noirq(struct device *dev)
 
 	if (!pm) {
 		pci_save_state(pci_dev);
-		goto Fixup;
+		goto set_unknown;
 	}
 
 	if (pm->suspend_noirq) {
@@ -923,6 +916,7 @@ static int pci_pm_suspend_noirq(struct device *dev)
 		goto Fixup;
 	}
 
+set_unknown:
 	pci_pm_set_unknown_state(pci_dev);
 
 	/*
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] PCI: Stop setting cached power state to 'unknown' on unbind

[sashiko-bot]

> From: Lukas Wunner <lukas@wunner.de>
> 
> [ Upstream commit d462c8e89e84bfb6417e6b4c88e0cb7cc747ba41 ]
> 
> When a PCI device is unbound from its driver, pci_device_remove() sets the
> cached power state in pci_dev->current_state to PCI_UNKNOWN.  This was
> introduced by commit 2449e06a5696 ("PCI: reset pci device state to unknown
> state for resume") to invalidate the cached power state in case the system
> is subsequently put to sleep.
> 
> For bound devices, the cached power state is set to PCI_UNKNOWN in
> pci_pm_suspend_noirq(), immediately before entering system sleep.
> 
> Extend to unbound devices for consistency.
> 
> This obviates the need to change the cached power state on unbind, so stop
> doing so.
> 
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> Link: https://patch.msgid.link/af7d11d3ceb231acc90829f7a5c8400c2446744f.1776415510.git.lukas@wunner.de
> Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

[PATCH AUTOSEL 6.18-5.10] PCI: iproc: Protect root bus removal with rescan lock

[Sasha Levin]

From: Hans Zhang <18255117159@163.com>

[ Upstream commit a6a64e150f12ad5391e0a0d60f6a3d119b06ce50 ]

Hold the pci_rescan_remove_lock lock while stopping and removing a root bus
to avoid racing with concurrent rescan or hotplug operations triggered via
sysfs.  Such races may lead to use-after-free issues or system crashes.

Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260521161822.132996-6-18255117159@163.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:** `[PCI: iproc]` `[Protect]` — Add missing
`pci_rescan_remove_lock` protection around root bus teardown in
`iproc_pcie_remove()`.

### Step 1.2: Commit Message Tags
**Record:**
- **Link:**
  `https://patch.msgid.link/20260521161822.132996-6-18255117159@163.com`
- **Signed-off-by:** Hans Zhang, Manivannan Sadhasivam, Bjorn Helgaas
- No `Fixes:`, `Reported-by:`, `Cc: stable@vger.kernel.org`, `Tested-
  by:`, or `Reviewed-by:` tags
- Notable: absence of `Fixes:`/`Cc: stable` is expected for manual
  review; not a negative signal

### Step 1.3: Commit Body Analysis
**Record:**
- **Bug:** `iproc_pcie_remove()` calls `pci_stop_root_bus()` /
  `pci_remove_root_bus()` without holding the global PCI rescan/remove
  mutex
- **Symptom:** Race with concurrent sysfs-triggered PCI rescan or
  hotplug → use-after-free or system crash
- **Root cause:** Driver teardown and sysfs rescan/remove paths can run
  concurrently on the same bus hierarchy without synchronization
- **Version info:** None in commit message

### Step 1.4: Hidden Bug Fix Detection
**Record:** Not disguised — explicitly a synchronization bug fix.
Matches a well-established PCI core pattern (`pci_lock_rescan_remove()`
/ `pci_unlock_rescan_remove()`).

---

## Phase 2: Diff Analysis

### Step 2.1: Change Inventory
**Record:**
- **File:** `drivers/pci/controller/pcie-iproc.c` (+2 lines)
- **Function:** `iproc_pcie_remove()`
- **Scope:** Single-file, surgical fix (2 insertions)

### Step 2.2: Code Flow Change
**Record:**
- **Before:** `pci_stop_root_bus()` → `pci_remove_root_bus()` with no
  lock
- **After:** `pci_lock_rescan_remove()` → stop/remove →
  `pci_unlock_rescan_remove()`
- **Path:** Driver remove (platform unbind, BCMA remove, module unload)

### Step 2.3: Bug Mechanism
**Record:**
- **Category:** Race condition / potential UAF
- **Mechanism:** `pci-sysfs.c` rescan/remove handlers (`rescan_store`,
  `dev_rescan_store`, `remove_store`, `bus_rescan_store`) hold
  `pci_rescan_remove_lock`. `iproc_pcie_remove()` did not. Concurrent
  sysfs operations and driver removal can corrupt or free PCI bus/device
  structures still in use.

### Step 2.4: Fix Quality
**Record:**
- Obviously correct — identical to `pci_host_common_remove()`, `pci-
  aardvark`, `pci-mvebu`, `pcie-mediatek-gen3`, `pci-hyperv`, and others
- Minimal, no API changes
- **Regression risk:** Very low; only serializes an already-required
  critical section

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:**
- `iproc_pcie_remove()` dates to Ray Jui (2015); `pci_stop_root_bus()` /
  `pci_remove_root_bus()` added in `81ce3cf4a246d` (2020, "PCI: iproc:
  Use pci_host_probe()")
- Unprotected removal pattern present since 2020 in this tree

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

### Step 3.3: Related File History
**Record:**
- Part of 9-patch series "[PATCH 0/9] PCI: controller: Add missing
  rescan lock around root bus removal"
- Cover letter states each patch is independent
- Same missing-lock pattern exists in several sibling drivers (cadence,
  dwc, altera, brcmstb, mediatek, rockchip, vmd, plda) — not yet fixed
  in this 6.18.44 tree

### Step 3.4: Author Context
**Record:** Hans Zhang is an active PCI contributor (cadence/dwc
capability search, etc.). Patch signed by PCI maintainer Bjorn Helgaas.

### Step 3.5: Dependencies
**Record:** None. `pci_lock_rescan_remove()` /
`pci_unlock_rescan_remove()` exist in this tree since commit
`9d16947b75831` (2014). `pcie-iproc.c` already includes `<linux/pci.h>`.
Standalone backport.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Discussion
**Record:**
- Commit not in local tree; `b4 dig -c` could not match it
- Local mbox/cover files available in workspace
- Cover letter lore reference: `https://lore.kernel.org/linux-
  pci/20260519132017.63E1BC2BCB3@smtp.kernel.org/` (sashiko-bot review
  flagging the missing-lock pattern)
- Series: v1, 9 independent patches, May 22 2026
- **UNVERIFIED:** Full lore thread replies (Anubis blocked WebFetch on
  lore.kernel.org)

### Step 4.2: Reviewers
**Record:** Cover letter references automated sashiko-bot review
identifying the race. Bjorn Helgaas committed. **UNVERIFIED:** Full
recipient list via `b4 dig -w` (commit not in tree).

### Step 4.3: Bug Reports
**Record:** No syzbot or user bug reports. Issue identified via code
review / pattern analysis (same class of bug Rafael Wysocki documented
in `9d16947b75831`).

### Step 4.4: Related Patches
**Record:** 8 sibling patches in the same series for other host
controllers; each independent.

### Step 4.5: Stable List History
**Record:** **UNVERIFIED** — could not search lore stable list
(blocked). No stable nomination found in local cover letter.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** `iproc_pcie_remove()` (modified)

### Step 5.2: Callers
**Record:**
- `iproc_pltfm_pcie_remove()` in `pcie-iproc-platform.c` (platform
  driver `.remove`)
- `iproc_bcma_pcie_remove()` in `pcie-iproc-bcma.c` (BCMA driver
  `.remove`)
- Triggered on device unbind, module unload, shutdown

### Step 5.3: Callees
**Record:** `pci_lock_rescan_remove()`, `pci_stop_root_bus()`,
`pci_remove_root_bus()`, `pci_unlock_rescan_remove()`, then MSI/PHY
cleanup

### Step 5.4: Reachability
**Record:**
- Driver remove is reachable on Broadcom iProc platforms
  (`CONFIG_PCIE_IPROC_PLATFORM`, `CONFIG_PCIE_IPROC_BCMA`)
- Concurrent sysfs PCI rescan/remove requires appropriate privileges
  (typically root), but is realistic during admin operations, hotplug
  testing, or scripted teardown
- Race window is real when both paths run concurrently

### Step 5.5: Similar Patterns
**Record:** Multiple controllers already use this lock pattern. `pcie-
iproc.c` is an outlier. `pci_stop_and_remove_bus_device()` asserts
`lockdep_assert_held(&pci_rescan_remove_lock)` — sysfs remove uses the
locked variant; host driver remove did not.

---

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

### Step 6.1: Buggy Code Exists?
**Record:** **YES.** At lines 1543–1544 of `drivers/pci/controller/pcie-
iproc.c`, `iproc_pcie_remove()` calls `pci_stop_root_bus()` /
`pci_remove_root_bus()` without the lock. Fix is **not** yet applied in
this tree (`git describe HEAD` → `v6.18.44-1-g2736c32da98b9`).

### Step 6.2: Backport Complications
**Record:** Clean apply expected — 2-line addition, no structural
conflicts. `pci_lock_rescan_remove` API unchanged.

### Step 6.3: Related Fixes Already Present?
**Record:** No equivalent fix for iproc in this tree. `pci-host-
common.c`, `pci-aardvark.c`, `pci-mvebu.c`, `pcie-mediatek-gen3.c`
already hold the lock.

---

## Phase 7: Subsystem Context

### Step 7.1: Subsystem and Criticality
**Record:** `drivers/pci/controller/` — **IMPORTANT** (PCI host
controller; affects platform-specific hardware but uses core PCI
infrastructure shared with sysfs paths)

### Step 7.2: Subsystem Activity
**Record:** Actively maintained; recent iproc commit `f37f2f804796e` in
this tree.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Users of Broadcom iProc PCIe (`ARCH_BCM_IPROC`, BCM5301X
BCMA). Not universal, but real production embedded/SoC deployments.

### Step 8.2: Trigger Conditions
**Record:** Driver remove/unbind concurrent with sysfs PCI rescan or
device removal. Uncommon but plausible under admin maintenance, module
reload, or testing. Requires privileges for sysfs side.

### Step 8.3: Failure Mode Severity
**Record:** Use-after-free / kernel crash — **HIGH** (potential
**CRITICAL** if exploited, though sysfs access limits practical
exploitability)

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** Prevents real race/UAF during teardown on affected
  hardware
- **Risk:** Minimal — 2 lines matching established PCI convention
- **Ratio:** Strongly favorable

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Fixes a real synchronization bug (race with sysfs PCI operations)
- Failure mode is UAF/system crash
- Fix is 2 lines, obviously correct, matches multiple existing drivers
  in this tree
- Bug has existed since 2020 when iproc adopted `pci_remove_root_bus()`
- No dependencies; API present since 2014
- Buggy code confirmed present in 6.18.44
- PCI maintainer committed the patch

**AGAINST backport:**
- No syzbot/user crash report (theoretical/code-review finding)
- Affects specific hardware platform only
- Part of a 9-patch series (but explicitly independent)

**Unresolved:**
- Full lore review thread and stable-list discussion (WebFetch blocked)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — matches established pattern;
   no functional change beyond serialization
2. Fixes a real bug? **PASS** — documented race with sysfs PCI paths
3. Important issue? **PASS** — UAF/crash severity HIGH
4. Small and contained? **PASS** — 2 lines, one function
5. No new features/APIs? **PASS**
6. Can apply to local tree? **PASS** — buggy code present, clean apply
   expected

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

### Step 9.4: Decision Rationale

For Linux **6.18.44**, `iproc_pcie_remove()` lacks the PCI rescan/remove
lock that sysfs PCI operations already use. This is a long-standing
oversight relative to the locking contract introduced in 2014 and
followed by `pci-host-common` and several other host drivers in this
tree. The fix is minimal, self-contained, and prevents a realistic race
during driver teardown that can cause use-after-free or crashes. It
meets all stable kernel criteria.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body from user-provided commit
  message and local mbox
- **[Phase 2]** Confirmed diff: +2 lines in `iproc_pcie_remove()`
  wrapping stop/remove with lock
- **[Phase 3]** `git describe HEAD`: v6.18.44; `git blame`: unprotected
  pattern since `81ce3cf4a246d` (2020)
- **[Phase 3]** `git show 9d16947b75831`: `pci_lock_rescan_remove()`
  introduced 2014, present in tree
- **[Phase 3]** Read local cover letter: 9-patch independent series,
  sashiko-bot flagged race
- **[Phase 4]** `b4 dig -c HEAD`: no match (commit not in tree)
- **[Phase 4]** Read `20260522_...rescan_lock...cover` and `.mbx`:
  series context and bot review
- **[Phase 4]** WebFetch lore/patch.msgid.link: blocked by Anubis —
  **UNVERIFIED** thread replies
- **[Phase 5]** `grep iproc_pcie_remove`: callers in `pcie-iproc-
  platform.c`, `pcie-iproc-bcma.c`
- **[Phase 5]** Read `pci-sysfs.c`: rescan/remove paths hold
  `pci_lock_rescan_remove()`
- **[Phase 5]** Read `pci-host-common.c`, `pci-aardvark.c`, `pci-
  mvebu.c`: established lock pattern
- **[Phase 5]** Read `remove.c`: `pci_stop_and_remove_bus_device()`
  asserts lock held
- **[Phase 6]** Read `pcie-iproc.c` lines 1539–1549: buggy code
  confirmed, fix absent
- **[Phase 6]** `grep CONFIG_PCIE_IPROC` in Kconfig: Broadcom iProc
  platforms
- **[Phase 8]** Assessed severity: UAF/crash, HIGH

**YES**

 drivers/pci/controller/pcie-iproc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
index 5aa677f81e4fa..61dcb232757fb 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -1540,8 +1540,10 @@ void iproc_pcie_remove(struct iproc_pcie *pcie)
 {
 	struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
 
+	pci_lock_rescan_remove();
 	pci_stop_root_bus(host->bus);
 	pci_remove_root_bus(host->bus);
+	pci_unlock_rescan_remove();
 
 	iproc_pcie_msi_disable(pcie);
 
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] PCI: iproc: Protect root bus removal with rescan lock

[sashiko-bot]

> From: Hans Zhang <18255117159@163.com>
> 
> [ Upstream commit a6a64e150f12ad5391e0a0d60f6a3d119b06ce50 ]
> 
> Hold the pci_rescan_remove_lock lock while stopping and removing a root bus
> to avoid racing with concurrent rescan or hotplug operations triggered via
> sysfs.  Such races may lead to use-after-free issues or system crashes.
> 
> Signed-off-by: Hans Zhang <18255117159@163.com>
> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
> [bhelgaas: commit log]
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Link: https://patch.msgid.link/20260521161822.132996-6-18255117159@163.com
> Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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