[PATCH AUTOSEL 7.0-6.12] drm/amdgpu: fix DF NULL pointer issue for soc24

[PATCH AUTOSEL 7.0-6.12] drm/amdgpu: fix DF NULL pointer issue for soc24

[Sasha Levin]

From: Likun Gao <Likun.Gao@amd.com>

[ Upstream commit 50808826a64b4957b7088c789e539dd0a75a1560 ]

If DF function not initialized, NULL pointer issue
will happen on soc24.

Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information I need. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
- **Subsystem:** `drm/amdgpu` (AMD GPU driver)
- **Action verb:** "fix" - explicitly a bug fix
- **Summary:** Fix NULL pointer dereference when DF functions are not
  initialized on soc24

Record: [drm/amdgpu] [fix] [NULL pointer dereference when df.funcs is
NULL in soc24_common_hw_init]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by:** Likun Gao (author)
- **Reviewed-by:** Hawking Zhang (AMD architect/maintainer for amdgpu)
- **Signed-off-by:** Alex Deucher (amdgpu subsystem maintainer)
- No Fixes: tag, no Cc: stable tag, no Reported-by (expected for manual
  review)

Record: Reviewed by Hawking Zhang (AMD subsystem architect) and merged
by Alex Deucher (amdgpu maintainer). Strong trust signal.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The body says: "If DF function not initialized, NULL pointer issue will
happen on soc24." This describes a concrete crash scenario: when
`adev->df.funcs` is NULL and code dereferences it to check `->hw_init`.

Record: [Bug: NULL pointer dereference] [Symptom: kernel oops/crash
during GPU hw_init or resume] [Root cause: missing NULL check before
dereferencing df.funcs pointer]

### Step 1.4: DETECT HIDDEN BUG FIXES
Not hidden - this is an explicit "fix" for a NULL pointer dereference.

Record: Not a hidden fix, explicitly labeled as a fix.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
- **Files:** 1 file changed (`drivers/gpu/drm/amd/amdgpu/soc24.c`)
- **Lines:** 1 line modified (replacing one condition with a guarded
  condition)
- **Function:** `soc24_common_hw_init()`
- **Scope:** Single-line surgical fix

Record: [soc24.c: 1 line changed in soc24_common_hw_init()] [Scope:
single-line surgical fix]

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Before:

```481:481:drivers/gpu/drm/amd/amdgpu/soc24.c
        if (adev->df.funcs->hw_init)
```

After:
```c
        if (adev->df.funcs && adev->df.funcs->hw_init)
```

The code was dereferencing `adev->df.funcs` (which can be NULL) to check
`hw_init`. The fix adds a NULL guard.

Record: [Before: unconditional dereference of df.funcs -> After: guarded
dereference with NULL check first]

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Category: NULL pointer dereference (d)**
- `adev->df.funcs` can be NULL if the DF IP version doesn't match any
  known version in `amdgpu_discovery.c`
- The code dereferences this NULL pointer to check `->hw_init`
- This causes a kernel oops

Record: [NULL pointer dereference] [df.funcs can be NULL when DF IP
version is unrecognized; the fix adds a standard guard consistent with
soc15.c patterns]

### Step 2.4: ASSESS THE FIX QUALITY
- Obviously correct: the pattern `if (ptr && ptr->member)` is idiomatic
  C null-guard
- Consistent: `soc15.c` already uses `if (adev->df.funcs &&
  adev->df.funcs->hw_init)` and `if (adev->df.funcs &&
  adev->df.funcs->sw_init)` - the exact same pattern
- Minimal: single condition addition, no behavior change when df.funcs
  is non-NULL
- Regression risk: zero - the only change is skipping the call when
  funcs is NULL (which would crash otherwise)

Record: [Obviously correct, minimal, zero regression risk. Matches
existing patterns in soc15.c]

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
The buggy line was introduced by commit `73048bda46c308` ("drm/amdgpu:
Fix atomics on GFX12") by David Belanger on 2024-06-10. This commit
added the DF hw_init call to soc24_common_hw_init but omitted the NULL
check for `adev->df.funcs`, unlike how soc15.c handles it.

Record: [Buggy code introduced by 73048bda46c308, present in v6.11+]

### Step 3.2: FOLLOW THE FIXES TAG
No Fixes: tag present (expected for review candidates).

Record: [No Fixes: tag, but the implicit fix target is 73048bda46c308]

### Step 3.3: CHECK FILE HISTORY
soc24.c was created by `98b912c50e449` (first in v6.11). The buggy
commit `73048bda46c308` was also added in v6.11. The file has had ~20
subsequent commits (refactoring handle pointers, etc.), but none touched
this specific df.funcs line.

Record: [Standalone fix, no prerequisites beyond the original buggy
commit]

### Step 3.4: CHECK THE AUTHOR
Likun Gao is a regular AMD GPU contributor with multiple recent commits
to the amdgpu subsystem. The reviewer (Hawking Zhang) is the original
soc24.c creator and AMD architect.

Record: [Author is a regular AMD contributor; reviewer is the subsystem
architect]

### Step 3.5: DEPENDENCIES
This fix has no dependencies. It simply adds a NULL check guard to an
existing conditional. It will apply to any tree that contains commit
`73048bda46c308`.

Record: [No dependencies, standalone fix]

---

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1: PATCH DISCUSSION
Found the original submission at
[spinics](https://www.spinics.net/lists/amd-gfx/msg138858.html).
Submitted by Alex Deucher on March 6, 2026. No objections or NAKs
visible. It was part of a batch of AMD GPU fixes.

Record: [Found submission on amd-gfx list, no objections, submitted in a
batch of fixes by the maintainer]

### Step 4.2: REVIEWERS
Reviewed by Hawking Zhang (AMD architect), signed off by Alex Deucher
(subsystem maintainer). Both are the top-level amdgpu maintainers.

Record: [Reviewed and merged by subsystem maintainers]

### Step 4.3-4.5: BUG REPORT / RELATED PATCHES / STABLE HISTORY
No syzbot report, no explicit bug report URL. This appears to be an
internally-discovered issue at AMD.

Record: [Internal AMD finding, no external bug report]

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.2: KEY FUNCTIONS AND CALLERS
`soc24_common_hw_init()` is called:
1. During GPU initialization via the `amd_ip_funcs` table (line 588:
   `.hw_init = soc24_common_hw_init`)
2. During resume via `soc24_common_resume()` (line 524-527)

Both are common execution paths for any system with soc24 hardware.

### Step 5.3-5.4: WHY df.funcs CAN BE NULL
In `amdgpu_discovery.c`, `adev->df.funcs` is set in a switch on
`DF_HWIP` version. The default case is `break` (no assignment). If a
soc24 device has a DF IP version not in the list, `df.funcs` remains
NULL. This is the exact trigger.

### Step 5.5: SIMILAR PATTERNS
Verified: `soc15.c` consistently uses the guarded pattern:
- Line 1253: `if (adev->df.funcs && adev->df.funcs->sw_init)`
- Line 1264: `if (adev->df.funcs && adev->df.funcs->sw_fini)`
- Line 1498: `if (adev->df.funcs &&
  adev->df.funcs->get_clockgating_state)`
- `gmc_v9_0.c` also guards with `if (adev->df.funcs && ...)`

soc24.c is the ONLY file missing this guard.

Record: [All other callers guard df.funcs with NULL check; soc24.c is
the sole exception]

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: BUGGY CODE IN STABLE TREES
- `soc24.c` first appeared in v6.11
- The buggy commit `73048bda46c308` is in v6.11+
- Therefore the bug exists in stable trees: **6.11.y, 6.12.y, 7.0.y**
- Not present in 6.6.y or earlier (soc24.c doesn't exist there)

Record: [Bug exists in 6.11.y, 6.12.y, 7.0.y]

### Step 6.2: BACKPORT COMPLICATIONS
The fix is a single-line change. No conflicting refactoring has touched
this specific line. Clean apply expected.

Record: [Expected clean apply to all affected stable trees]

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
- **Subsystem:** GPU driver (drm/amdgpu) - IMPORTANT
- AMD GPUs are extremely common in desktop and laptop systems
- soc24 corresponds to RDNA4 generation (GC 12.0.x) - recent and
  actively shipping hardware

Record: [drm/amdgpu] [IMPORTANT - affects users of recent AMD GPUs]

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
All users with soc24 (RDNA4) AMD GPU hardware where the DF IP version
doesn't match a listed version in discovery.

### Step 8.2: TRIGGER CONDITIONS
The crash triggers during:
- GPU hardware initialization (every boot)
- GPU resume from suspend (every suspend/resume cycle)
These are unavoidable common paths.

### Step 8.3: FAILURE MODE SEVERITY
**CRITICAL** - NULL pointer dereference causes a kernel oops, crashing
the system during boot or resume. The GPU driver is essential for
display output.

### Step 8.4: RISK-BENEFIT RATIO
- **Benefit:** Prevents kernel oops on boot/resume for soc24 users -
  VERY HIGH
- **Risk:** 1-line addition of a NULL check, zero chance of regression -
  VERY LOW
- **Ratio:** Extremely favorable

Record: [Benefit: VERY HIGH (prevents crash), Risk: VERY LOW (1-line
NULL guard)]

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: EVIDENCE COMPILATION

**FOR backporting:**
- Fixes a NULL pointer dereference (kernel oops/crash)
- Affects GPU init and resume paths (common, unavoidable paths)
- Single-line fix, obviously correct
- Matches existing defensive patterns in soc15.c, gmc_v9_0.c,
  amdgpu_ras.c
- Reviewed by AMD architect (Hawking Zhang), merged by subsystem
  maintainer (Alex Deucher)
- Zero regression risk
- Affects actively-shipping hardware (RDNA4)

**AGAINST backporting:**
- None identified

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** - standard NULL guard, matches
   existing patterns, reviewed by maintainers
2. Fixes a real bug? **YES** - NULL pointer dereference → kernel oops
3. Important issue? **YES** - system crash during GPU init/resume
   (CRITICAL)
4. Small and contained? **YES** - 1 line changed in 1 file
5. No new features or APIs? **YES** - purely defensive check
6. Can apply to stable? **YES** - clean apply expected for 6.11.y+

### Step 9.3: EXCEPTION CATEGORIES
Not an exception case; this is a standard bug fix that meets all normal
criteria.

### Step 9.4: DECISION
This is a textbook stable backport candidate: a one-line NULL pointer
check that prevents a kernel oops during GPU initialization and resume
on recent AMD hardware.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by: Hawking Zhang, SOB: Likun Gao,
  Alex Deucher
- [Phase 2] Diff analysis: 1 line changed in soc24_common_hw_init(),
  adds `adev->df.funcs &&` guard
- [Phase 3] git blame: buggy code introduced in commit 73048bda46c308
  (v6.11), "Fix atomics on GFX12"
- [Phase 3] git merge-base: confirmed 73048bda46c308 is in v6.11+,
  soc24.c first added in v6.11
- [Phase 4] Found original submission at spinics amd-gfx list, no NAKs
  or concerns
- [Phase 5] Grep for `adev->df.funcs`: soc15.c, gmc_v9_0.c, amdgpu_ras.c
  all use NULL guard; soc24.c is the only exception
- [Phase 5] amdgpu_discovery.c: df.funcs assignment has a `default:
  break` that leaves funcs NULL for unrecognized DF versions
- [Phase 5] soc24_common_resume() calls soc24_common_hw_init(),
  confirming crash on both init and resume
- [Phase 6] Bug exists in 6.11.y, 6.12.y, 7.0.y; not in 6.6.y or earlier
  (soc24.c not present)
- [Phase 8] Failure mode: NULL deref -> kernel oops during GPU
  init/resume, severity CRITICAL

**YES**

 drivers/gpu/drm/amd/amdgpu/soc24.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/soc24.c b/drivers/gpu/drm/amd/amdgpu/soc24.c
index ecb6c3fcfbd15..984262936545f 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc24.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc24.c
@@ -484,7 +484,7 @@ static int soc24_common_hw_init(struct amdgpu_ip_block *ip_block)
 	if (adev->nbio.funcs->remap_hdp_registers)
 		adev->nbio.funcs->remap_hdp_registers(adev);
 
-	if (adev->df.funcs->hw_init)
+	if (adev->df.funcs && adev->df.funcs->hw_init)
 		adev->df.funcs->hw_init(adev);
 
 	/* enable the doorbell aperture */
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] drm/amd/display: remove duplicate format modifier

[Sasha Levin]

From: Erik Kurzinger <ekurzinger@gmail.com>

[ Upstream commit 6736c8ff9d63e847a3b694aeaeb78d4e8ad42464 ]

amdgpu_dm_plane_get_plane_modifiers always adds DRM_FORMAT_MOD_LINEAR to
the list of modifiers. However, with gfx12,
amdgpu_dm_plane_add_gfx12_modifiers also adds that modifier to the list.
So we end up with two copies. Most apps just ignore this but some
(Weston) don't like it.

As a fix, we change amdgpu_dm_plane_add_gfx12_modifiers to not add
DRM_FORMAT_MOD_LINEAR to the list, matching the behavior of analogous
functions for other chips.

Signed-off-by: Erik Kurzinger <ekurzinger@gmail.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for the analysis. Let me compile
the findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
Record: [drm/amd/display] [remove] Remove duplicate
DRM_FORMAT_MOD_LINEAR format modifier in gfx12 modifiers list.

**Step 1.2: Tags**
- Signed-off-by: Erik Kurzinger <ekurzinger@gmail.com> (author)
- Acked-by: Alex Deucher <alexander.deucher@amd.com> (AMD subsystem
  maintainer)
- Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (merged by
  maintainer)
- No Fixes: tag, no Cc: stable, no Reported-by — all expected for
  AUTOSEL candidates.

**Step 1.3: Commit Body**
The commit message clearly describes:
`amdgpu_dm_plane_get_plane_modifiers` always adds
`DRM_FORMAT_MOD_LINEAR` at the end of the modifier list for all chips
(line 769). But `amdgpu_dm_plane_add_gfx12_modifiers` also includes
`DRM_FORMAT_MOD_LINEAR` in its own `gfx12_modifiers[]` array, causing it
to appear twice. Most compositors ignore duplicates, but Weston
compositor breaks when it encounters them.

Record: Bug = duplicate format modifier in the kernel-to-userspace
modifier list for gfx12 GPUs. Symptom = Weston compositor malfunctions
on gfx12 hardware.

**Step 1.4: Hidden Bug Fix**
This is unambiguously a bug fix — it fixes incorrect behavior that
breaks a real compositor (Weston). The word "remove" understates the fix
— this corrects a real user-visible bug.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed:
  `drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c`
- ~4 lines of functional change within
  `amdgpu_dm_plane_add_gfx12_modifiers()`
- Scope: single-file, single-function surgical fix

**Step 2.2: Code Flow Changes**
1. `gfx12_modifiers[]` array: `DRM_FORMAT_MOD_LINEAR` removed from the
   array (5 elements → 4)
2. DCC loop: `ARRAY_SIZE(gfx12_modifiers) - 1` →
   `ARRAY_SIZE(gfx12_modifiers)` (now iterates over ALL tiled modifiers
   for DCC, since there's no LINEAR to skip)
3. Comments updated to explain the caller adds LINEAR for all chips

**Step 2.3: Bug Mechanism**
Category: Logic/correctness fix. The gfx12 function inconsistently added
LINEAR while all other gfx functions (gfx9, gfx10_1, gfx10_3, gfx11)
rely on the caller to add it. Verified by grepping — only gfx12 had
LINEAR in its internal list.

**Step 2.4: Fix Quality**
Obviously correct — makes gfx12 match the pattern of all other chip
functions. Minimal, surgical. Zero regression risk to other chips. The
loop bound fix is critical: without it, removing LINEAR from the array
would cause the DCC loop to skip the last real modifier (mod_256b).

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
The buggy `DRM_FORMAT_MOD_LINEAR` in the `gfx12_modifiers[]` array was
introduced by commit `21e6f6085bbc97` ("drm/amd/display: Allow display
DCC for DCN401", Aurabindo Pillai, 2024-07-03), which restructured the
gfx12 function to add DCC support. The original gfx12 function
(`a64a521231a46`, 2024-02-02) also had LINEAR inline, but pre-DCC. Both
are in v6.11+.

**Step 3.2: Fixes target**
No Fixes: tag. The bug was introduced by `21e6f6085bbc97` (v6.11). This
commit exists in stable trees 6.11.y, 6.12.y, 6.13.y, 6.14.y.

**Step 3.3: File History**
Recent changes to the file are unrelated (color pipeline, kmalloc
conversions). No prerequisites or dependencies found.

**Step 3.4: Author**
Erik Kurzinger is a DRM contributor (drm/syncobj patches). Alex Deucher,
who Acked and merged, is the AMD subsystem maintainer.

**Step 3.5: Dependencies**
The fix is completely standalone. The only context dependency is that
`max_comp_block[] = {2, 1, 0}` in v6.15+ vs `{1, 0}` in 6.11-6.14 (from
commit `3855f1d925d4f`), but this is in context lines, not in the
changed lines. Minor context fuzz at most.

---

## PHASE 4: MAILING LIST RESEARCH

- Patch v1 was posted on Feb 10, 2026. Alex Deucher immediately Acked
  it.
- v2 was submitted the same day with improved comments and the loop
  bound fix. Alex Deucher Acked v2 as well.
- No NAKs or concerns raised. No explicit stable nomination, but also no
  objection.
- b4 dig could not find the AMD patches on lore (AMD patches go through
  freedesktop gitlab, not always indexed by b4).

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.4: Function and Call Chain**
- `amdgpu_dm_plane_add_gfx12_modifiers()` is called from
  `amdgpu_dm_plane_get_plane_modifiers()` for AMDGPU_FAMILY_GC_12_0_0
  devices.
- `amdgpu_dm_plane_get_plane_modifiers()` is called during plane
  initialization (`amdgpu_dm_plane_init()`), which runs for every
  display plane on every gfx12 GPU.
- The modifier list is exported to userspace via the DRM plane
  properties and queried by compositors like Weston when selecting
  buffer formats.

**Step 5.5: Similar Patterns**
Confirmed: gfx9, gfx10_1, gfx10_3, and gfx11 functions do NOT add
`DRM_FORMAT_MOD_LINEAR`. Only gfx12 was inconsistent.

---

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code Presence**
- gfx12 modifiers introduced in v6.11 (a64a521231a46)
- DCC restructuring (introducing the duplicate) also in v6.11
  (21e6f6085bbc97)
- Bug exists in: **6.11.y, 6.12.y, 6.13.y, 6.14.y** stable trees
- Not in v6.10 or earlier (no gfx12 support)

**Step 6.2: Backport Complications**
For 6.11-6.14: `max_comp_block[] = {1, 0}` (context-only difference from
`{2, 1, 0}` in 6.15+). The actual changed lines are identical. Should
apply with minor fuzz or a trivial context adjustment.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1:** drm/amd/display — IMPORTANT subsystem. AMD GPUs
(especially gfx12 = RDNA4) are widely used in desktops and embedded
systems. Display bugs affect all users of the GPU.

**Step 7.2:** The file is actively maintained with frequent changes.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
All users of gfx12 (AMDGPU RDNA4) GPUs running Weston compositor. Also
potentially affects other compositors that validate modifier lists
strictly.

**Step 8.2: Trigger Conditions**
100% triggered on every gfx12 GPU initialization — the duplicate
modifier is always present in the exported list.

**Step 8.3: Failure Mode Severity**
Weston compositor fails to work properly with gfx12 GPUs. Severity:
MEDIUM-HIGH. This prevents a major compositor from functioning on new
AMD hardware.

**Step 8.4: Risk-Benefit**
- Benefit: HIGH — fixes Weston on gfx12, corrects API contract (DRM
  modifiers should not have duplicates)
- Risk: VERY LOW — 4-line change in a single function, matching
  established pattern of all other chip functions, Acked by maintainer
- Ratio: Very favorable

---

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Fixes a real bug that breaks Weston compositor on gfx12 hardware
- Small, surgical, obviously correct (4 functional line changes)
- Matches the established pattern of all other chip generations
- Acked by subsystem maintainer (Alex Deucher)
- Bug present in all stable trees with gfx12 support (6.11+)
- Zero regression risk to other chips
- No new features or APIs

**Evidence AGAINST backporting:**
- Impact is limited to Weston users on gfx12 (most compositors tolerate
  duplicates)
- No CVE, no crash, no data corruption

**Stable Rules Checklist:**
1. Obviously correct and tested? **YES** — matches all other chip
   functions, Acked by maintainer
2. Fixes a real bug? **YES** — duplicate modifier breaks Weston
3. Important issue? **MEDIUM-HIGH** — prevents compositor from working
   on new hardware
4. Small and contained? **YES** — 4 lines, 1 function, 1 file
5. No new features or APIs? **YES**
6. Can apply to stable? **YES** — may need minor context adjustment for
   6.11-6.14

---

## Verification

- [Phase 1] Parsed tags: Acked-by Alex Deucher (AMD maintainer), no
  Fixes/Cc-stable (expected)
- [Phase 2] Diff analysis: 4 functional lines changed in
  `amdgpu_dm_plane_add_gfx12_modifiers()`, removes LINEAR from array and
  fixes loop bound
- [Phase 2] Confirmed all other gfx add functions (gfx9, gfx10_1,
  gfx10_3, gfx11) do NOT add LINEAR — verified via grep
- [Phase 2] Confirmed caller `amdgpu_dm_plane_get_plane_modifiers()`
  adds LINEAR at line 769 for ALL chips — verified via Read
- [Phase 3] git blame: buggy line 707 introduced by commit
  21e6f6085bbc97 (v6.11, 2024-07-03)
- [Phase 3] git show a64a521231a46: original gfx12 function also had
  LINEAR (duplicate from day one)
- [Phase 3] Verified gfx12 NOT in v6.10, IS in v6.11+ via `git merge-
  base --is-ancestor`
- [Phase 3] 3855f1d925d4f (max_comp_block context change) in v6.15 only
  — minor context fuzz for older stables
- [Phase 4] Found patch v1 and v2 on freedesktop.org mailing list
  archives
- [Phase 4] v1 (1-line change) and v2 (4-line change with improved
  comments/loop) both Acked by Alex Deucher
- [Phase 4] No NAKs, no concerns raised in discussion
- [Phase 5] Verified call chain: `amdgpu_dm_plane_init()` →
  `amdgpu_dm_plane_get_plane_modifiers()` →
  `amdgpu_dm_plane_add_gfx12_modifiers()` — runs on every gfx12 display
  plane init
- [Phase 6] Bug present in 6.11.y, 6.12.y, 6.13.y, 6.14.y stable trees
  (verified)
- [Phase 8] Failure mode: Weston compositor broken on gfx12, severity
  MEDIUM-HIGH

**YES**

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
index 127207e18dcb0..bc19438211dd3 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
@@ -704,21 +704,21 @@ static void amdgpu_dm_plane_add_gfx12_modifiers(struct amdgpu_device *adev,
 	uint8_t max_comp_block[] = {2, 1, 0};
 	uint64_t max_comp_block_mod[ARRAY_SIZE(max_comp_block)] = {0};
 	uint8_t i = 0, j = 0;
-	uint64_t gfx12_modifiers[] = {mod_256k, mod_64k, mod_4k, mod_256b, DRM_FORMAT_MOD_LINEAR};
+	/* Note, linear (no DCC) gets added to the modifier list for all chips by the caller. */
+	uint64_t gfx12_modifiers[] = {mod_256k, mod_64k, mod_4k, mod_256b};
 
 	for (i = 0; i < ARRAY_SIZE(max_comp_block); i++)
 		max_comp_block_mod[i] = AMD_FMT_MOD_SET(DCC_MAX_COMPRESSED_BLOCK, max_comp_block[i]);
 
 	/* With DCC: Best choice should be kept first. Hence, add all 256k modifiers of different
 	 * max compressed blocks first and then move on to the next smaller sized layouts.
-	 * Do not add the linear modifier here, and hence the condition of size-1 for the loop
 	 */
-	for (j = 0; j < ARRAY_SIZE(gfx12_modifiers) - 1; j++)
+	for (j = 0; j < ARRAY_SIZE(gfx12_modifiers); j++)
 		for (i = 0; i < ARRAY_SIZE(max_comp_block); i++)
 			amdgpu_dm_plane_add_modifier(mods, size, capacity,
 						     ver | dcc | max_comp_block_mod[i] | gfx12_modifiers[j]);
 
-	/* Without DCC. Add all modifiers including linear at the end */
+	/* Without DCC. */
 	for (i = 0; i < ARRAY_SIZE(gfx12_modifiers); i++)
 		amdgpu_dm_plane_add_modifier(mods, size, capacity, gfx12_modifiers[i]);
 
-- 
2.53.0

[PATCH AUTOSEL 7.0] drm/amdgpu/userq: unlock cancel_delayed_work_sync for hang_detect_work

[Sasha Levin]

From: Sunil Khatri <sunil.khatri@amd.com>

[ Upstream commit f802f7b0bc0917023f4b5938246fd7abf23fa5e3 ]

cancel_delayed_work_sync for work hand_detect_work should not be
locked since the amdgpu_userq_hang_detect_work also need the same
mutex and when they run together it could be a deadlock.

we do not need to hold the mutex for
cancel_delayed_work_sync(&queue->hang_detect_work). With this in place
if cancel and worker thread run at same time they will not deadlock.

Due to any failures if there is a hand detect and reset that there a
deadlock scenarios between cancel and running the main thread.

[ 243.118276] task:kworker/9:0 state:D stack:0 pid:73 tgid:73 ppid:2 task_flags:0x4208060 flags:0x00080000
[ 243.118283] Workqueue: events amdgpu_userq_hang_detect_work [amdgpu]
[ 243.118636] Call Trace:
[ 243.118639] <TASK>
[ 243.118644] __schedule+0x581/0x1810
[ 243.118649] ? srso_return_thunk+0x5/0x5f
[ 243.118656] ? srso_return_thunk+0x5/0x5f
[ 243.118659] ? wake_up_process+0x15/0x20
[ 243.118665] schedule+0x64/0xe0
[ 243.118668] schedule_preempt_disabled+0x15/0x30
[ 243.118671] __mutex_lock+0x346/0x950
[ 243.118677] __mutex_lock_slowpath+0x13/0x20
[ 243.118681] mutex_lock+0x2c/0x40
[ 243.118684] amdgpu_userq_hang_detect_work+0x63/0x90 [amdgpu]
[ 243.118888] process_scheduled_works+0x1f0/0x450
[ 243.118894] worker_thread+0x27f/0x370
[ 243.118899] kthread+0x1ed/0x210
[ 243.118903] ? __pfx_worker_thread+0x10/0x10
[ 243.118906] ? srso_return_thunk+0x5/0x5f
[ 243.118909] ? __pfx_kthread+0x10/0x10
[ 243.118913] ret_from_fork+0x10f/0x1b0
[ 243.118916] ? __pfx_kthread+0x10/0x10
[ 243.118920] ret_from_fork_asm+0x1a/0x30

Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have the full picture. Here is my complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
Record: [drm/amdgpu/userq] [unlock/fix] Move `cancel_delayed_work_sync`
for `hang_detect_work` outside the mutex to prevent a deadlock.

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>** - author,
  regular AMD GPU contributor
- **Reviewed-by: Christian Konig <christian.koenig@amd.com>** - key
  DRM/AMDGPU maintainer/reviewer
- **Signed-off-by: Alex Deucher <alexander.deucher@amd.com>** - AMDGPU
  subsystem maintainer who committed it
- No Fixes: tag (expected for candidates under review)
- No Cc: stable (expected)
- No Reported-by tag, but includes a stack trace showing the actual
  deadlock

Record: Reviewed by Christian Konig (senior AMDGPU developer), committed
by Alex Deucher (subsystem maintainer). Stack trace provided.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit describes a classic AB-BA deadlock:
- `amdgpu_userq_destroy()` holds `userq_mutex` and calls
  `cancel_delayed_work_sync(&queue->hang_detect_work)`
- `amdgpu_userq_hang_detect_work()` tries to acquire `userq_mutex`
- When both run concurrently, deadlock occurs: destroy waits for work to
  finish, work waits for mutex

The commit includes a full kernel stack trace showing the deadlock in
action (task stuck in `D` state waiting on `__mutex_lock` inside the
workqueue worker for `amdgpu_userq_hang_detect_work`).

Record: Classic deadlock. Symptom is system hang (task in D state).
Triggered when queue destruction races with pending hang detection work.

### Step 1.4: DETECT HIDDEN BUG FIXES
This is explicitly a deadlock fix, not disguised at all. The title says
"unlock" and the body describes the deadlock mechanism clearly.

Record: Not hidden. Explicit deadlock fix.

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
- **File**: `drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c`
- **Function modified**: `amdgpu_userq_destroy()`
- **Lines added**: ~4 (cancel + NULL assignment moved)
- **Lines removed**: ~4 (old placement removed)
- **Scope**: Single-file, single-function surgical fix

Record: 1 file, 1 function, net change ~0 lines (code reorganization).
Surgical fix.

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Before**: `cancel_delayed_work_sync(&queue->hang_detect_work)` was
called INSIDE `mutex_lock(&uq_mgr->userq_mutex)`, conditionally (only if
`hang_detect_fence` is set).

**After**: `cancel_delayed_work_sync(&queue->hang_detect_work)` is
called BEFORE `mutex_lock(&uq_mgr->userq_mutex)`, unconditionally. Then
`queue->hang_detect_fence = NULL` is set after acquiring the mutex.

Record: cancel_delayed_work_sync moved outside mutex scope; conditional
removed (cancel is safe to call unconditionally).

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Category**: Deadlock (ABBA lock ordering)

The deadlock path:
1. Thread A (destroy path): `mutex_lock(&uq_mgr->userq_mutex)` ->
   `cancel_delayed_work_sync(&queue->hang_detect_work)` [waits for work
   to finish]
2. Thread B (worker): `amdgpu_userq_hang_detect_work()` ->
   `mutex_lock(&uq_mgr->userq_mutex)` [waits for mutex]

Thread A holds the mutex and waits for the work to complete. The work
holds the CPU and waits for the mutex. Classic deadlock.

Record: ABBA deadlock between userq_mutex and cancel_delayed_work_sync.

### Step 2.4: ASSESS THE FIX QUALITY
- **Obviously correct**: Yes. Moving `cancel_delayed_work_sync` outside
  the mutex breaks the deadlock cycle. `cancel_delayed_work_sync` is
  documented as safe to call on uninitialized or never-scheduled work
  items.
- **Minimal/surgical**: Yes. Only reorders existing operations in one
  function.
- **Regression risk**: Very low. Removing the conditional `if
  (queue->hang_detect_fence)` check is safe because
  `cancel_delayed_work_sync` on a work that hasn't been scheduled is a
  no-op. Setting `hang_detect_fence = NULL` after the mutex is acquired
  is still correct as it's protecting the shared state.

Record: Obviously correct, minimal, very low regression risk.

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
The buggy code was introduced by commit `fc3336be9c629` (Jesse.Zhang,
2026-01-13) which first appeared in v7.0-rc1. This commit added the
`hang_detect_work` mechanism and placed the `cancel_delayed_work_sync`
call inside the mutex lock in `amdgpu_userq_destroy`.

Record: Buggy code introduced in fc3336be9c629, first present in
v7.0-rc1.

### Step 3.2: FOLLOW THE FIXES TAG
No Fixes: tag present. However, the implicit Fixes target is
`fc3336be9c629` which added the hang_detect_work feature with the
deadlock bug.

Record: Implicitly fixes fc3336be9c629 (v7.0-rc1).

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
The file has been heavily modified. Notable: commit `65b5c326ce410`
(refcount userqueues, 2026-03-02) also touches `amdgpu_userq_destroy()`
but did NOT fix this deadlock. That refcount commit has `Cc:
stable@vger.kernel.org`.

Record: The refcount commit (already marked for stable) still has this
deadlock. The fix is standalone.

### Step 3.4: CHECK THE AUTHOR
Sunil Khatri is a regular AMD GPU driver contributor with 10+ commits in
this subsystem. The fix was reviewed by Christian Konig, a key AMDGPU
maintainer.

Record: Experienced contributor; reviewed by subsystem expert.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
The fix applies to the code as it exists in v7.0 (post-fc3336be9c629).
The refcount rework (`65b5c326ce410`) changed the function signature but
did not change the deadlock pattern. The fix needs to be checked for
whether it applies to the pre- or post-refcount version of the code. In
v7.0, the code has the old (non-refcount) signature. The fix targets the
post-refcount version (based on the diff showing
`amdgpu_userq_destroy(struct amdgpu_userq_mgr *uq_mgr, struct
amdgpu_usermode_queue *queue)` instead of `amdgpu_userq_destroy(struct
drm_file *filp, int queue_id)`).

Record: The fix targets the post-refcount version. For v7.0.y, the
refcount commit (`65b5c326ce410`) would need to be applied first (it's
already marked Cc: stable).

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1-4.5
b4 dig could not find the specific commit because it hasn't been
committed to mainline yet (it's a candidate). The refcount commit series
was found on lore. Web search for the deadlock fix patch was blocked by
Anubis bot protection on lore.kernel.org.

Record: Lore investigation limited by anti-scraping measures. Based on
code analysis alone, the deadlock is verified.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: KEY FUNCTIONS
- `amdgpu_userq_destroy()` - the function being fixed
- `amdgpu_userq_hang_detect_work()` - the work handler that creates the
  deadlock

### Step 5.2: TRACE CALLERS
`amdgpu_userq_destroy()` is called from `amdgpu_userq_kref_destroy()`
(line 680), which is the kref release callback. This is triggered via
`amdgpu_userq_put()` (line 701), called when the last reference to a
userqueue is dropped. This happens during:
- Queue destruction IOCTL (user-initiated)
- fini path (cleanup on file descriptor close)

Record: Called during normal queue teardown - common user-triggered
operation.

### Step 5.3-5.4: CALL CHAIN
User -> IOCTL -> `amdgpu_userq_put()` -> `kref_put()` ->
`amdgpu_userq_kref_destroy()` -> `amdgpu_userq_destroy()` [holds mutex]
-> `cancel_delayed_work_sync()` [deadlocks if work is running].

The hang detect work is scheduled during normal fence operations via
`amdgpu_userq_start_hang_detect_work()`, called from
`amdgpu_userq_fence.c`.

Record: Both paths are reachable from normal userspace operations. The
race window is between submitting GPU work (which schedules hang
detection) and destroying a queue.

### Step 5.5: SIMILAR PATTERNS
The `cancel_delayed_work_sync(&uq_mgr->resume_work)` calls throughout
the file are already placed OUTSIDE the mutex (e.g., lines 632, 1391,
1447, etc.), demonstrating the correct pattern. The `hang_detect_work`
cancellation was the only instance that violated this pattern.

Record: All other cancel_delayed_work_sync calls in this file follow the
correct pattern (outside mutex).

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
- **v6.19.y**: `hang_detect_work` does NOT exist. The file exists but
  the feature was not added until v7.0-rc1.
- **v7.0.y**: The bug EXISTS. The `hang_detect_work` was introduced in
  v7.0-rc1 by `fc3336be9c629`.
- No earlier stable trees (6.12.y, 6.6.y, etc.) are affected.

Record: Bug exists ONLY in 7.0.y.

### Step 6.2: BACKPORT COMPLICATIONS
The fix's diff shows the post-refcount function signature
(`amdgpu_userq_destroy(struct amdgpu_userq_mgr *uq_mgr, struct
amdgpu_usermode_queue *queue)`). The v7.0 release has the OLD signature.
The refcount commit (`65b5c326ce410`) is already marked `Cc: stable` and
must be applied first for this fix to apply cleanly.

Record: Needs refcount commit as prerequisite. Minor conflicts possible
if refcount is not applied.

### Step 6.3: RELATED FIXES ALREADY IN STABLE
No related fix for this specific deadlock has been found.

Record: No alternative fix exists.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM AND CRITICALITY
- **Subsystem**: DRM/AMDGPU (GPU drivers)
- **Criticality**: IMPORTANT - AMD GPUs are widely used in desktops,
  laptops, and workstations. Userqueues are a new feature in 7.0 for
  user-mode GPU scheduling.

Record: IMPORTANT subsystem. Affects AMD GPU users with userqueue-
enabled hardware.

### Step 7.2: SUBSYSTEM ACTIVITY
The file has 59 commits between v6.19 and v7.0 - extremely active
development. Userqueue support is new infrastructure being actively
developed.

Record: Very active subsystem. New feature code.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
Users with AMD GPUs that use the new userqueue feature
(AMDGPU_CAP_USERQ). This is new GPU scheduling infrastructure.

Record: AMD GPU users with userqueue support enabled.

### Step 8.2: TRIGGER CONDITIONS
The deadlock is triggered when:
1. A delayed `hang_detect_work` is pending (scheduled after a fence
   submission)
2. The user destroys the queue (via IOCTL or process exit)
3. The work fires and tries to acquire the mutex at the same time

This is a realistic race window, especially during error scenarios (the
hang detection work has a timeout-based delay).

Record: Triggered during queue destruction with pending hang detection.
Realistic race window.

### Step 8.3: FAILURE MODE SEVERITY
**CRITICAL**: System deadlock. Tasks enter D state (uninterruptible
sleep) and cannot be killed. The stack trace in the commit message
confirms this - the system hangs.

Record: System deadlock/hang. Severity: CRITICAL.

### Step 8.4: RISK-BENEFIT RATIO
- **Benefit**: Prevents a deadlock that hangs the system. HIGH benefit.
- **Risk**: Minimal. Reordering a cancel_delayed_work_sync before a
  mutex_lock is obviously correct. The pattern matches all other similar
  calls in the same file. VERY LOW risk.

Record: Benefit HIGH, Risk VERY LOW. Strongly favorable ratio.

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**Evidence FOR backporting:**
- Fixes a real, reproducible deadlock (stack trace provided)
- Deadlock leads to system hang (CRITICAL severity)
- Small, surgical fix (reordering ~4 lines in one function)
- Obviously correct (matches the pattern used everywhere else in the
  file)
- Reviewed by Christian Konig (key AMDGPU maintainer)
- Committed by Alex Deucher (subsystem maintainer)
- The bug exists in v7.0 release

**Evidence AGAINST backporting:**
- No Fixes: tag (expected, not a negative signal)
- The feature (`hang_detect_work`) is new in v7.0, so only affects 7.0.y
  stable
- May require the refcount prerequisite commit (`65b5c326ce410`, already
  Cc: stable) to apply cleanly

**UNRESOLVED:**
- Could not verify if the exact commit SHA exists in mainline (the fix
  may be pending in a subsystem tree)
- Mailing list discussion not accessible due to lore anti-scraping

### Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES - stack trace demonstrates the
   bug, fix is logically obvious
2. **Fixes a real bug?** YES - deadlock
3. **Important issue?** YES - system deadlock/hang (CRITICAL)
4. **Small and contained?** YES - ~8 line change in one function
5. **No new features or APIs?** YES - just reorders existing code
6. **Can apply to stable trees?** YES (7.0.y), with refcount commit
   prerequisite

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Not an exception category - this is a standard bug fix (deadlock).

### Step 9.4: MAKE YOUR DECISION
This is a clear deadlock fix for code in v7.0. The fix is small,
obviously correct, reviewed by the right people, and prevents a system
hang. It meets all stable kernel criteria.

## Verification

- [Phase 1] Parsed tags: Reviewed-by Christian Konig, Signed-off-by Alex
  Deucher (subsystem maintainer). Stack trace in commit message.
- [Phase 2] Diff analysis: ~8 lines changed in `amdgpu_userq_destroy()`,
  moves `cancel_delayed_work_sync` before `mutex_lock`
- [Phase 2] Verified `amdgpu_userq_hang_detect_work()` acquires
  `uq_mgr->userq_mutex` at line 168
- [Phase 2] Verified `amdgpu_userq_destroy()` acquires same mutex at
  line 633, then calls `cancel_delayed_work_sync` at line 637 while
  holding it
- [Phase 3] git blame: buggy code introduced by `fc3336be9c629`
  (Jesse.Zhang, 2026-01-13), first in v7.0-rc1
- [Phase 3] `git tag --contains fc3336be9c629`: confirmed present in
  v7.0-rc1 and v7.0
- [Phase 3] Author Sunil Khatri has 10+ commits in amdgpu subsystem
- [Phase 5] Verified all other `cancel_delayed_work_sync` calls in the
  file are placed OUTSIDE the mutex (correct pattern)
- [Phase 5] Traced call chain: IOCTL -> `amdgpu_userq_put()` ->
  `kref_put()` -> `amdgpu_userq_kref_destroy()` ->
  `amdgpu_userq_destroy()`
- [Phase 6] Verified `hang_detect_work` does NOT exist in v6.19.12 (grep
  returned 0 matches)
- [Phase 6] Bug exists ONLY in v7.0.y
- [Phase 6] Prerequisite: refcount commit `65b5c326ce410` (already Cc:
  stable) may be needed for clean apply
- UNVERIFIED: Could not access lore.kernel.org discussion due to anti-
  scraping protection
- UNVERIFIED: Could not confirm the mainline commit SHA (the fix is not
  yet in this tree's git log)

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
index e8d12556d690a..ad39460b54dc5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
@@ -630,13 +630,14 @@ amdgpu_userq_destroy(struct amdgpu_userq_mgr *uq_mgr, struct amdgpu_usermode_que
 	int r = 0;
 
 	cancel_delayed_work_sync(&uq_mgr->resume_work);
+
+	/* Cancel any pending hang detection work and cleanup */
+	cancel_delayed_work_sync(&queue->hang_detect_work);
+
 	mutex_lock(&uq_mgr->userq_mutex);
+	queue->hang_detect_fence = NULL;
 	amdgpu_userq_wait_for_last_fence(queue);
-	/* Cancel any pending hang detection work and cleanup */
-	if (queue->hang_detect_fence) {
-		cancel_delayed_work_sync(&queue->hang_detect_work);
-		queue->hang_detect_fence = NULL;
-	}
+
 	r = amdgpu_bo_reserve(queue->db_obj.obj, true);
 	if (!r) {
 		amdgpu_bo_unpin(queue->db_obj.obj);
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.1] drm/amd/display: Merge pipes for validate

[Sasha Levin]

From: Harry Wentland <harry.wentland@amd.com>

[ Upstream commit 606f6b171326152ef08d0ef0ad49f52034edca07 ]

Validation expects to operate on non-split pipes. This is
seen in dcn20_fast_validate_bw, which merges pipes for
validation. We weren't doing that in the non-fast path
which lead to validation failures when operating with
4-to-1 MPC and a writeback connector.

Co-developed by Claude Sonnet 4.5

Assisted-by: Claude:claude-sonnet-4.5
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: `drm/amd/display` (AMD display driver, DCN30
  specifically)
- **Action verb**: "Merge" (in the sense of merging split pipes before
  validation)
- **Summary**: Adds pipe merge step before validation in dcn30 non-fast
  path, matching the fast path behavior.

Record: [drm/amd/display] [merge/fix] [Add missing pipe merge call
before validation to match fast-validate path]

### Step 1.2: Tags
- **Fixes:** NONE (expected for autosel candidate)
- **Cc: stable:** NONE (expected for autosel candidate)
- **Co-developed by Claude Sonnet 4.5** - AI-assisted development
- **Assisted-by:** Claude:claude-sonnet-4.5
- **Reviewed-by:** Nicholas Kazlauskas (AMD display engineer)
- **Signed-off-by:** Harry Wentland (AMD display developer), Chuanyu
  Tseng, Alex Deucher (AMD DRM maintainer)
- **Reported-by:** NONE

Record: No Fixes tag, no Cc stable, no Reported-by. Reviewed by AMD
display expert. Signed by AMD DRM maintainer. No user bug reports.

### Step 1.3: Commit Body Text
The commit says: "Validation expects to operate on non-split pipes. This
is seen in dcn20_fast_validate_bw, which merges pipes for validation. We
weren't doing that in the non-fast path which lead to validation
failures when operating with 4-to-1 MPC and a writeback connector."

Bug: `dcn30_internal_validate_bw` passes split pipe configurations to
DML validation, but DML expects merged (non-split) pipes.
Symptom: Validation failures with 4-to-1 MPC split + writeback
connector.
Root cause: Missing `dcn20_merge_pipes_for_validate()` call that
dcn20_fast_validate_bw already has.

Record: [Validation expects non-split pipes; DCN30 non-fast path missed
merge call] [Validation failures with 4-to-1 MPC + writeback] [No
version info] [Same pattern as dcn20/dcn21 fast-validate]

### Step 1.4: Hidden Bug Fix Detection
This is NOT hidden - it clearly describes a validation failure bug and
the fix.

Record: [Explicit bug fix - validation failures on specific
configuration]

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files**: 1 file (`dcn30_resource.c`), +2 lines added (function call
  + blank line)
- **Functions modified**: `dcn30_internal_validate_bw`
- **Scope**: Single-file, single-line surgical fix

Record: [1 file, +2 lines] [dcn30_internal_validate_bw] [Single-line
surgical fix]

### Step 2.2: Code Flow Change
- **Before**: `dcn30_internal_validate_bw` immediately proceeds to set
  DML parameters and populate DML pipes without merging previously-split
  pipes.
- **After**: Before setting DML parameters, it calls
  `dcn20_merge_pipes_for_validate(dc, context)` to merge ODM-split and
  MPC-split pipes back into their head pipes, matching what
  `dcn20_fast_validate_bw` does.

The merge function (already existing in dcn20_resource.c, lines
1792-1849):
1. Merges ODM-split pipes by unlinking the chain
2. Merges MPC-split pipes by removing bottom_pipe entries
3. Both needed "since mode support needs to make the decision"

Record: [Before: validate with split pipes (wrong)] [After: merge pipes
first, then validate (correct, matching dcn20/dcn21)]

### Step 2.3: Bug Mechanism
This is a **logic/correctness fix**. The DML validation expects a single
non-split pipe view and makes its own split decisions. When pipes are
already split from a previous configuration, the validation gets
confused about pipe counts and resources, leading to false validation
failures.

Record: [Logic correctness bug] [DML fed split pipes when it expects
non-split pipes; fixes false validation failures]

### Step 2.4: Fix Quality
- **Obviously correct**: YES - directly matches the established pattern
  in `dcn20_fast_validate_bw` (line 2057) and dcn21's validate function
  (line 812)
- **Minimal/surgical**: YES - 1 line of actual code
- **Regression risk**: Extremely low - calling existing, well-tested
  function at the correct location
- **Red flags**: None

Record: [Obviously correct, matches established pattern] [No regression
risk from the fix itself]

## PHASE 3: GIT HISTORY

### Step 3.1: Blame
- `dcn30_internal_validate_bw` was introduced by `5dba4991fd338d`
  (2020-05-21, "drm/amd/display: Add DCN3 Resource")
- The merge logic was available via `dcn20_merge_pipes_for_validate`
  since `ea817dd5ad7950` (2020-09-18, "drm/amd/display: add dcn21 bw
  validation")
- The bug has existed since DCN3 was first added (v5.9)
- `dcn20_resource.h` is already included by dcn30_resource.c (line 34)

Record: [Buggy code from 5dba4991fd338d, introduced in v5.9] [Bug
present in all stable trees with DCN3 support]

### Step 3.2: Fixes Tag
No Fixes: tag present. The bug was introduced when DCN3 resource was
added without the merge call.

### Step 3.3: Related Changes
- Commit `269c1d1443d668` (2025-05-14) changed `fast_validate` to `enum
  dc_validate_mode` - affects function signature but NOT the insertion
  point
- Commit `71c4ca2d3b079d` (2023-02-01) added `allow_self_refresh_only`
  parameter

Record: [Standalone fix, no prerequisites] [May need minor context
adjustment for older stable trees]

### Step 3.4: Author
Harry Wentland is a well-known AMD display developer and regular
contributor. Alex Deucher is the AMD DRM maintainer.

Record: [Authored by established AMD display developer, signed off by
subsystem maintainer]

### Step 3.5: Dependencies
The commit calls `dcn20_merge_pipes_for_validate()` which has existed
since v5.10+. The function is declared in `dcn20_resource.h` which is
already included. No new dependencies.

Record: [No dependencies, function already exists and is accessible]

## PHASE 4: MAILING LIST RESEARCH

I was unable to find the original patch submission on lore.kernel.org
due to anti-bot protections. Web searches found related AMD display work
by the same authors but not this specific patch.

Record: [UNVERIFIED - could not find original lore discussion] [No
stable-specific discussion found]

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Functions Modified
Only `dcn30_internal_validate_bw` is modified.

### Step 5.2: Callers
`dcn30_internal_validate_bw` is called from:
1. `dcn30_validate_bandwidth` (dcn30_resource.c:2091) - main validation
   entry point for DCN3.0
2. `dcn31_validate_bandwidth` (dcn31_resource.c:1812) - DCN3.1
3. `dcn314_validate_bandwidth` (dcn314_resource.c:1751) - DCN3.14
4. `dcn30_fpu.c` (lines 342, 634) - called in loops for dummy pstate and
   watermark calculations

This means the fix affects ALL DCN 3.x generations.

### Step 5.3-5.4: Call Chain
Display mode validation → `dcn30_validate_bandwidth` →
`dcn30_internal_validate_bw` → DML validation
This is triggered during every mode set/display configuration change.

Record: [Called during every mode set on DCN 3.0/3.1/3.14 hardware]
[Affects RDNA 2 GPUs (RX 6000), Rembrandt APUs, Phoenix APUs]

### Step 5.5: Similar Patterns
Confirmed: `dcn20_fast_validate_bw` at line 2057 and dcn21's validate
function at line 812 both already call `dcn20_merge_pipes_for_validate`
in the exact same position.

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable Trees
DCN3 support (and `dcn30_internal_validate_bw`) has been present since
v5.9. All active stable trees (6.1.y, 6.6.y, 6.12.y) contain this code.

### Step 6.2: Backport Complications
The function signature changed over time:
- v6.1/v6.6: has `bool fast_validate` parameter
- v6.12+: has `enum dc_validate_mode validate_mode`
- The insertion point (after `if (!pipes) return false;`, before
  `maxMpcComb = 0`) is stable across versions
- Minor context adjustment may be needed for older trees

Record: [Likely clean apply or trivial conflict on most stable trees]

### Step 6.3: Related Fixes Already in Stable
No related fixes found for the same issue.

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem Criticality
- **Subsystem**: drm/amd/display - display driver for AMD GPUs
- **Criticality**: IMPORTANT - AMD RDNA 2/3 GPUs are among the most
  widely deployed discrete GPUs
- DCN3.0 covers RX 6000 series, DCN3.1 covers Ryzen 6000 mobile APUs

### Step 7.2: Subsystem Activity
Very active subsystem with frequent changes.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
Users with AMD RDNA 2+ hardware (RX 6000 series, Ryzen 6000+ APUs) who
use display configurations triggering 4-to-1 MPC split with writeback.
This is driver-specific but on very popular hardware.

### Step 8.2: Trigger Conditions
- Requires 4-to-1 MPC pipe split (high resolution/bandwidth scenarios)
- Plus writeback connector active (screen capture, virtual display)
- Not a common everyday trigger, but can occur with specific display
  configurations

### Step 8.3: Failure Mode
Validation failure → mode set fails → display configuration rejected
Severity: MEDIUM-HIGH (can cause display output failure)

### Step 8.4: Risk-Benefit Ratio
- **Benefit**: Prevents display validation failures on widely deployed
  hardware
- **Risk**: Extremely low (1-line change, calling existing well-tested
  function)
- **Ratio**: Strongly favorable for backporting

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting:**
- Fixes a real validation failure bug (display config rejection)
- Extremely surgical: 1 line of actual code
- Matches established pattern in dcn20/dcn21 (proven correct)
- Zero regression risk
- Affects widely deployed hardware (AMD RDNA 2+)
- Affects multiple DCN generations (3.0, 3.1, 3.14 all call this
  function)
- Bug has existed since v5.9 (long-standing)
- Reviewed by AMD display expert (Nicholas Kazlauskas)
- Signed off by AMD DRM maintainer (Alex Deucher)
- Function already exists and is included via header

**AGAINST backporting:**
- Specific trigger condition (4-to-1 MPC + writeback)
- No Fixes: tag, no Cc: stable (expected)
- No user bug reports (Reported-by)
- Writeback connector usage is relatively niche
- Co-developed with AI (unusual, though reviewed by expert)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** - matches exact pattern in
   dcn20/dcn21
2. Fixes a real bug? **YES** - validation failures with specific
   configuration
3. Important issue? **MEDIUM** - display config rejection, not
   crash/security
4. Small and contained? **YES** - 1 line in 1 file
5. No new features or APIs? **YES** - just calls existing function
6. Can apply to stable? **YES** - insertion point is stable across
   versions

### Step 9.3: Exception Categories
Not an exception category - this is a standard bug fix.

### Step 9.4: Decision
The fix is extremely low risk (single function call, well-established
pattern) and prevents real validation failures on popular AMD hardware.
While the specific trigger (4-to-1 MPC + writeback) is not common in
everyday use, the fix has virtually zero regression potential and
corrects a clear inconsistency between the DCN20/21 and DCN30 validation
paths.

## Verification

- [Phase 1] Parsed tags: Reviewed-by Nicholas Kazlauskas, SOBs from
  Wentland/Tseng/Deucher, Co-developed by AI
- [Phase 2] Diff analysis: +2 lines (1 function call + blank line) in
  dcn30_internal_validate_bw
- [Phase 2] Verified dcn20_fast_validate_bw at line 2057 already has
  identical call
- [Phase 2] Verified dcn21 validate function at line 812 already has
  identical call
- [Phase 3] git blame: dcn30_internal_validate_bw introduced in
  5dba4991fd338d (2020-05-21, v5.9)
- [Phase 3] git blame: dcn20_merge_pipes_for_validate introduced in
  ea817dd5ad7950 (2020-09-18)
- [Phase 3] Verified dcn30_resource.c includes dcn20/dcn20_resource.h at
  line 34
- [Phase 3] Verified function signature changes: validate_mode in
  269c1d1443d66 (2025), allow_self_refresh_only in 71c4ca2d3b079d (2023)
- [Phase 5] Confirmed callers: dcn30_validate_bandwidth, dcn31, dcn314,
  dcn30_fpu.c (multiple call sites)
- [Phase 5] Verified dcn20_merge_pipes_for_validate function body (lines
  1792-1849): merges ODM and MPC splits
- [Phase 6] Confirmed DCN3 present in stable trees since v5.9 (tag
  contains check)
- [Phase 6] maxMpcComb=0 line (context) confirmed present since v6.1
  (4931ce22eca6ed)
- UNVERIFIED: Could not access lore.kernel.org for mailing list
  discussion due to anti-bot protections
- UNVERIFIED: Could not find original patch submission via b4 dig or web
  search

**YES**

 drivers/gpu/drm/amd/display/dc/resource/dcn30/dcn30_resource.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn30/dcn30_resource.c b/drivers/gpu/drm/amd/display/dc/resource/dcn30/dcn30_resource.c
index 87b7b4ee04c64..b00054ea18178 100644
--- a/drivers/gpu/drm/amd/display/dc/resource/dcn30/dcn30_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/resource/dcn30/dcn30_resource.c
@@ -1675,6 +1675,8 @@ noinline bool dcn30_internal_validate_bw(
 	if (!pipes)
 		return false;
 
+	dcn20_merge_pipes_for_validate(dc, context);
+
 	context->bw_ctx.dml.vba.maxMpcComb = 0;
 	context->bw_ctx.dml.vba.VoltageLevel = 0;
 	context->bw_ctx.dml.vba.DRAMClockChangeSupport[0][0] = dm_dram_clock_change_vactive;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] drm/amd/display: Fix cursor pos at overlay plane edges on DCN4

[Sasha Levin]

From: Ivan Lipski <ivan.lipski@amd.com>

[ Upstream commit d8f6c978fd3d12ae129879dd1c514cec2e8cf2f8 ]

[Why&How]
On DCN4, when cursor straddles the left/top edge of an overlay plane, the
recout-relative position becomes negative. These negative values wrap
to large positive numbers when cast to uint32_t, causing the cursor on the
the overlay plane to disappear.

Fix by adding hotspot adjustment and position clamping after the
recout-relative calculation, matching the existing ODM/MPC slice
boundary handling.

Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a comprehensive analysis. Let
me compile everything.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: drm/amd/display (AMD display controller, DCN4
  specifically)
- **Action verb**: "Fix" - explicit bug fix
- **Summary**: Fixes cursor position bug at overlay plane edges on DCN4
  hardware

### Step 1.2: Tags
- **Reviewed-by**: Nicholas Kazlauskas (AMD display driver maintainer) -
  strong quality signal
- **Signed-off-by**: Ivan Lipski (author), Alex Deucher (AMD GPU
  maintainer)
- **Tested-by**: Dan Wheeler (AMD QA)
- No Fixes: tag, no Cc: stable, no Reported-by - expected for manual
  review candidates

### Step 1.3: Body Text
The bug mechanism is clearly explained: On DCN4, when the cursor
straddles the left/top edge of an overlay plane, the recout-relative
position calculation produces negative values. These negative values
wrap to large positive numbers when cast to uint32_t, causing the cursor
to disappear. The fix adds hotspot adjustment and position clamping,
matching the existing ODM/MPC slice boundary handling pattern.

### Step 1.4: Hidden Bug Fix Detection
Not hidden at all - this is explicitly labeled as a bug fix with a clear
mechanism described.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **1 file changed**:
  `drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c`
- **+19 lines**, 0 lines removed
- **Function modified**: `dcn401_set_cursor_position()`
- **Scope**: Single-file, single-function surgical fix

### Step 2.2: Code Flow Change
**Before**: After `x_pos = pos_cpy.x - param.recout.x` (line 1211),
negative x_pos values flow directly to `pos_cpy.x = x_pos` (line 1229),
wrapping the uint32_t to a huge positive number.

**After**: Negative x_pos/y_pos values are clamped to 0 with
corresponding hotspot adjustment, preventing the uint32_t wrapping.

### Step 2.3: Bug Mechanism
This is a **type/casting bug** (integer underflow). Negative int values
wrap when assigned to uint32_t, causing the cursor to be positioned far
offscreen and effectively disappear.

### Step 2.4: Fix Quality
- Obviously correct: matches the existing ODM/MPC boundary handling
  already in the same function (lines 1177-1187)
- Minimal/surgical: 19 lines added, all in one block
- Low regression risk: only affects cursor rendering when cursor is at
  overlay plane edges, does not affect normal cursor positioning
- No API or behavioral changes for other paths

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
The recout-relative code was introduced by commit `ee8287e068a399` ("Fix
cursor issues with ODMs and HW rotations") by Nevenko Stupar, which
landed in v6.11-rc1. However, the specific bug was **exposed** by commit
`c02288724b98c` ("Fix wrong x_pos and y_pos for cursor offload") by
Nicholas Kazlauskas, which added the `pos_cpy.x = x_pos; pos_cpy.y =
y_pos;` lines that store the recout-relative position into the uint32_t
pos_cpy struct. This commit only exists in **v7.0-rc1 onwards**.

### Step 3.2: Prerequisite Analysis
Commit c02288724b98c is critical. It moved cursor position storage from
the HUBP layer to the HWSS layer. Before this commit (in v6.12, v6.14,
v6.19), pos_cpy.x was NOT updated with recout-relative values, so the
negative wrapping didn't occur in the HWSS path. In older trees, HUBP
did its own translation separately.

### Step 3.3: Related Changes
Many cursor-related fixes have been applied to this file (cursor
offload, ODM issues, MPC slices). This fix is standalone and doesn't
depend on other patches in the series.

### Step 3.4: Author
Ivan Lipski is an AMD display driver contributor. The reviewer Nicholas
Kazlauskas is a key AMD display maintainer who also authored the
prerequisite commit c02288724b98c.

### Step 3.5: Dependencies
- **Depends on c02288724b98c** being present (adds `pos_cpy.x = x_pos;`
  lines). This commit exists in v7.0 but NOT in v6.19 or earlier.
- The fix is standalone within v7.0 - doesn't need any other patches
  from its series.

---

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1: Original Submission
Found via web search. The patch was submitted February 18, 2026 as
[PATCH 2/9] in "DC Patches February 18, 2026" series. No objections or
NAKs were raised in the thread. Only one version (no v2/v3).

### Step 4.2: Reviewers
CC list includes all major AMD display maintainers: Harry Wentland, Leo
Li, Aurabindo Pillai, Roman Li, Wayne Lin, Tom Chung, Nicholas
Kazlauskas, Alex Hung, Dan Wheeler. Review-by from Nicholas Kazlauskas
confirms subsystem maintainer review.

### Step 4.3-4.5: No specific bug report referenced, no stable-specific
discussion found.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.2: Function Context
`dcn401_set_cursor_position()` is called from the hardware sequencer
path for all cursor position updates on DCN4 hardware. It's a commonly-
triggered path - every cursor movement goes through it.

### Step 5.3: Fix Pattern
The fix exactly mirrors the existing ODM slice boundary handling at
lines 1177-1187 of the same function:

```1177:1187:drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c
        if (x_pos < 0) {
                pos_cpy.x_hotspot -= x_pos;
                if
(hubp->curs_attr.attribute_flags.bits.ENABLE_MAGNIFICATION)
adjust_hotspot_between_slices_for_2x_magnify(hubp->curs_attr.width,
&pos_cpy);
                x_pos = 0;
        }

        if (y_pos < 0) {
                pos_cpy.y_hotspot -= y_pos;
                y_pos = 0;
        }
```

The new code reuses the same pattern at a different point in the
function.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable Trees
- **v6.12, v6.14, v6.19**: The recout-relative calculation exists, but
  `pos_cpy.x = x_pos;` (c02288724b98c) does NOT. The bug doesn't
  manifest in these trees.
- **v7.0**: Both the recout calculation AND `pos_cpy.x = x_pos;` exist.
  The bug is present.

### Step 6.2: Backport Complications
For v7.0.y: The patch should apply cleanly. The context lines match
exactly.
For 6.19.y and earlier: The fix would be irrelevant as the prerequisite
c02288724b98c doesn't exist.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem
- **drivers/gpu/drm/amd/display** - AMD display controller driver
- **Criticality**: IMPORTANT - affects all users of AMD DCN4 (RDNA 4)
  GPUs using overlay planes

### Step 7.2: Activity
Very actively developed subsystem with dozens of commits per release
cycle.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
Users of AMD RDNA 4 (DCN4) GPUs who use overlay planes with cursor
visible near the plane edges. This includes desktop users with
compositors using overlay planes.

### Step 8.2: Trigger Conditions
Moving the mouse cursor near the left/top edge of an overlay plane.
Common in multi-window scenarios and video playback with overlay. Can be
triggered by any user.

### Step 8.3: Failure Mode
Cursor disappears when near overlay plane edges. **Severity: MEDIUM-
HIGH** - not a crash or data corruption, but a visible rendering glitch
that makes the system harder to use.

### Step 8.4: Risk-Benefit
- **Benefit**: HIGH - fixes cursor disappearing for all DCN4 users with
  overlay planes
- **Risk**: VERY LOW - 19 lines, mirrors existing pattern, only affects
  cursor rendering, reviewed by subsystem maintainer
- **Ratio**: Very favorable

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting:**
- Fixes a real, user-visible bug (cursor disappearing)
- Small, surgical fix (19 lines added, single function)
- Pattern is well-established in the same function
- Reviewed by AMD display maintainer (Nicholas Kazlauskas)
- Tested by AMD QA (Dan Wheeler)
- No objections during review
- Cleanly applies to v7.0

**AGAINST backporting:**
- Only affects DCN4 (newer AMD GPUs) - narrower user base than core
  kernel
- Symptom is cosmetic (cursor disappears), not a crash or security issue
- Bug only exists in v7.0+ (due to prerequisite c02288724b98c)
- Cannot apply to 6.19.y or earlier stable trees without also
  backporting c02288724b98c

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** - mirrors existing pattern,
   Tested-by AMD QA
2. Fixes a real bug? **YES** - cursor disappears at overlay plane edges
3. Important issue? **YES** - user-visible rendering bug affecting
   usability
4. Small and contained? **YES** - 19 lines, single function, single file
5. No new features? **YES** - pure bug fix
6. Can apply to stable? **YES** for 7.0.y; **NO** for older trees
   (missing prerequisite)

### Step 9.3: Exception Categories
Not an exception category - this is a standard bug fix.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Nicholas Kazlauskas, Tested-by Dan
  Wheeler, SOBs from Ivan Lipski and Alex Deucher
- [Phase 2] Diff analysis: +19 lines in `dcn401_set_cursor_position()`,
  adds negative position clamping with hotspot adjustment
- [Phase 3] git blame: recout-relative code from ee8287e068a399 (v6.11),
  bug exposed by c02288724b98c (v7.0-rc1)
- [Phase 3] git show c02288724b98c: confirmed it adds `pos_cpy.x =
  x_pos;` lines, only in v7.0+
- [Phase 3] Verified v6.12 code does NOT have `pos_cpy.x = x_pos;` - bug
  doesn't manifest there
- [Phase 3] Verified v6.14 and v6.19 code also lacks `pos_cpy.x =
  x_pos;` - same conclusion
- [Phase 4] Found original submission on freedesktop.org mailing list
  (Feb 18, 2026): patch 2/9 in DC Patches series
- [Phase 4] No NAKs or objections; reviewed by subsystem maintainer
- [Phase 5] Confirmed pattern matches existing ODM boundary handling at
  lines 1177-1187 of same function
- [Phase 6] Verified buggy code exists in v7.0 (confirmed `pos_cpy.x =
  x_pos` present and no clamping)
- [Phase 6] Verified patch context lines match v7.0 tree - will apply
  cleanly
- [Phase 8] Failure mode: cursor disappears at overlay edges, severity
  MEDIUM-HIGH (usability impact)

The fix is small, surgical, obviously correct, fixes a real user-visible
bug on DCN4 hardware, follows established code patterns, and was
properly reviewed and tested by AMD's display team. It applies cleanly
to the 7.0.y stable tree where the bug exists.

**YES**

 .../amd/display/dc/hwss/dcn401/dcn401_hwseq.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c
index 4dfb6c8658312..4973d36aadc5d 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c
@@ -1211,6 +1211,25 @@ void dcn401_set_cursor_position(struct pipe_ctx *pipe_ctx)
 	x_pos = pos_cpy.x - param.recout.x;
 	y_pos = pos_cpy.y - param.recout.y;
 
+	/**
+	 * If the cursor position is negative after recout adjustment, we need
+	 * to shift the hotspot to compensate and clamp position to 0. This
+	 * handles the case where cursor straddles the left/top edge of an
+	 * overlay plane - the cursor is partially visible and needs correct
+	 * hotspot adjustment to render the visible portion.
+	 */
+	if (x_pos < 0) {
+		pos_cpy.x_hotspot -= x_pos;
+		if (hubp->curs_attr.attribute_flags.bits.ENABLE_MAGNIFICATION)
+			adjust_hotspot_between_slices_for_2x_magnify(hubp->curs_attr.width, &pos_cpy);
+		x_pos = 0;
+	}
+
+	if (y_pos < 0) {
+		pos_cpy.y_hotspot -= y_pos;
+		y_pos = 0;
+	}
+
 	recout_x_pos = x_pos - pos_cpy.x_hotspot;
 	recout_y_pos = y_pos - pos_cpy.y_hotspot;
 
-- 
2.53.0

[PATCH AUTOSEL 6.18] drm/amdgpu: Handle GPU page faults correctly on non-4K page systems

[Sasha Levin]

From: Donet Tom <donettom@linux.ibm.com>

[ Upstream commit 4e9597f22a3cb8600c72fc266eaac57981d834c8 ]

During a GPU page fault, the driver restores the SVM range and then maps it
into the GPU page tables. The current implementation passes a GPU-page-size
(4K-based) PFN to svm_range_restore_pages() to restore the range.

SVM ranges are tracked using system-page-size PFNs. On systems where the
system page size is larger than 4K, using GPU-page-size PFNs to restore the
range causes two problems:

Range lookup fails:
Because the restore function receives PFNs in GPU (4K) units, the SVM
range lookup does not find the existing range. This will result in a
duplicate SVM range being created.

VMA lookup failure:
The restore function also tries to locate the VMA for the faulting address.
It converts the GPU-page-size PFN into an address using the system page
size, which results in an incorrect address on non-4K page-size systems.
As a result, the VMA lookup fails with the message: "address 0xxxx VMA is
removed".

This patch passes the system-page-size PFN to svm_range_restore_pages() so
that the SVM range is restored correctly on non-4K page systems.

Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Donet Tom <donettom@linux.ibm.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 074fe395fb13247b057f60004c7ebcca9f38ef46)
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index f2e00f408156c..69080e3734891 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2960,14 +2960,14 @@ bool amdgpu_vm_handle_fault(struct amdgpu_device *adev, u32 pasid,
 	if (!root)
 		return false;
 
-	addr /= AMDGPU_GPU_PAGE_SIZE;
-
 	if (is_compute_context && !svm_range_restore_pages(adev, pasid, vmid,
-	    node_id, addr, ts, write_fault)) {
+	    node_id, addr >> PAGE_SHIFT, ts, write_fault)) {
 		amdgpu_bo_unref(&root);
 		return true;
 	}
 
+	addr /= AMDGPU_GPU_PAGE_SIZE;
+
 	r = amdgpu_bo_reserve(root, true);
 	if (r)
 		goto error_unref;
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] drm/amd/display: bios_parser: fix GPIO I2C line off-by-one

[Sasha Levin]

From: Pengpeng Hou <pengpeng@iscas.ac.cn>

[ Upstream commit 12fa1fd6dffff4eed15f1414eb7474127b2c5a24 ]

get_gpio_i2c_info() computes the number of GPIO I2C assignment records
present in the BIOS table and then uses bfI2C_LineMux as an array index
into header->asGPIO_Info[]. The current check only rejects values
strictly larger than the record count, so an index equal to count still
falls through and reaches the fixed table one element past the end.

Reject indices at or above the number of available records before using
them as an array index.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: drm/amd/display (AMD display driver, BIOS parser)
- **Action verb**: "fix" — explicitly a bug fix
- **Summary**: Fixes an off-by-one error in GPIO I2C line bounds
  checking in the BIOS parser

### Step 1.2: Tags
- **Signed-off-by**: Pengpeng Hou <pengpeng@iscas.ac.cn> — the author
- **Signed-off-by**: Alex Deucher <alexander.deucher@amd.com> — AMD DRM
  subsystem maintainer, merged the patch
- No Fixes: tag (expected for AUTOSEL candidates)
- No Reported-by, no Tested-by, no Reviewed-by
- No Cc: stable (expected)

### Step 1.3: Commit Body Analysis
The commit message clearly explains the bug mechanism:
- `get_gpio_i2c_info()` computes the number of GPIO I2C records in the
  BIOS table
- `bfI2C_LineMux` is used as an array index into `header->asGPIO_Info[]`
- Current check rejects values **strictly larger** than record count,
  but allows index **equal** to count
- Index equal to count accesses one element past the end (classic off-
  by-one)
- **Symptom**: Out-of-bounds array read accessing uninitialized BIOS
  data

### Step 1.4: Hidden Bug Fix?
No — this is explicitly labeled as a bug fix. The commit message clearly
describes the off-by-one mechanism.

Record: This is an explicitly stated off-by-one out-of-bounds array
access fix.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Change Inventory
- **Files changed**: 1
  (`drivers/gpu/drm/amd/display/dc/bios/bios_parser.c`)
- **Lines changed**: 1 line modified (single character: `<` → `<=`)
- **Function modified**: `get_gpio_i2c_info()`
- **Scope**: Single-file, single-character surgical fix

### Step 2.2: Code Flow Change

```1957:1957:drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
        if (count < record->sucI2cId.bfI2C_LineMux)
```

**Before**: `count < bfI2C_LineMux` — rejects only when index > count.
When index == count, the check passes but the access at
`header->asGPIO_Info[count]` is one past the last valid entry (valid
indices are 0..count-1).

**After**: `count <= bfI2C_LineMux` — rejects when index >= count,
correctly limiting access to indices 0..count-1.

### Step 2.3: Bug Mechanism
**Category**: Buffer overflow / out-of-bounds read (off-by-one)

The `asGPIO_Info` array has `ATOM_MAX_SUPPORTED_DEVICE` (16) elements in
the struct definition, but `count` is computed from the BIOS table's
reported structure size and represents how many entries the BIOS
actually initialized. Reading at index `count` accesses either:
- Uninitialized BIOS data within the struct, OR
- Beyond the actual BIOS table data (if the table is exactly sized)

The result is used to populate `info->gpio_info.*` fields including
register indices and shift values, which are then used for actual
hardware register access. Reading garbage values could lead to incorrect
register reads/writes.

### Step 2.4: Fix Quality
- **Obviously correct**: Yes — textbook off-by-one fix. Array of `count`
  elements, valid indices 0..count-1, must reject index >= count.
- **Minimal**: Maximally minimal — single character change.
- **Regression risk**: Essentially zero — the fix only tightens a bounds
  check. The only behavioral change is rejecting the boundary case that
  was previously allowed (and was incorrect).

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
All lines in the affected function trace back to commit `4562236b3bc0a2`
("drm/amd/dc: Add dc display driver (v2)") by Harry Wentland, dated
2017-09-12. This is the **initial import** of the AMD DC display driver.
The bug has been present since **v4.15** — it exists in ALL stable trees
that contain this driver.

### Step 3.2: No Fixes: tag present (expected)
The implicit Fixes: target is `4562236b3bc0a2` — the initial driver
import.

### Step 3.3: File History
Recent file changes are mostly feature additions (DAC/encoder support,
logging changes) and treewide cleanups. None touch the
`get_gpio_i2c_info()` function — this code has been stable/unchanged
since 2017.

### Step 3.4: Author
Pengpeng Hou has multiple commits in the tree, all small bounds-checking
fixes (NFC, networking, Bluetooth, tracing). This is consistent — the
author appears to systematically audit bounds checking across the
kernel.

### Step 3.5: Dependencies
None. This is a completely standalone one-character fix with no
prerequisites.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1-4.2: Patch Discussion
b4 dig could not find the original submission (likely too recent or
submitted through AMD's drm tree). The patch was signed off by Alex
Deucher, the AMD DRM subsystem maintainer, indicating it passed review
through the normal AMD DRM merge path.

### Step 4.3: Related Fixes
Web search found historical AUTOSEL patches for BIOS parser OOB issues
(`4fc1ba4aa589` by Aurabindo Pillai, `d116db180decec1b` by Mario
Limonciello), but those addressed a **different** issue — `gpio_pin`
array hardcoded to size 8 in bios_parser2.c/atomfirmware.h. The current
fix is for bios_parser.c (v1 parser) and a different bounds check.

### Step 4.4-4.5: No stable-specific discussion found for this exact
fix.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.2: Call Chain
- `get_gpio_i2c_info()` is called from `bios_parser_get_i2c_info()`
- This is registered as the `.get_i2c_info` callback in the BIOS parser
  vtable
- Callers:
  1. `dce_i2c.c` line 45: `dcb->funcs->get_i2c_info(dcb, id, &i2c_info)`
     — OEM I2C setup
  2. `link_ddc.c` line 123: `dcb->funcs->get_i2c_info(dcb,
     init_data->id, &i2c_info)` — DDC (Display Data Channel)
     initialization for monitor connections

### Step 5.3-5.4: Impact Surface
Both callers are in the display initialization path:
- `link_ddc.c` is called during DDC service creation, which happens for
  **every display output** during driver initialization
- `dce_i2c.c` is called for OEM I2C device setup
- These paths are triggered during boot/display setup on ALL AMD GPU
  systems using the older BIOS parser (pre-ATOM v2 firmware)

### Step 5.5: Similar Patterns
The parallel `bios_parser2.c` (for newer GPUs) uses a different approach
— iterating with `for (table_index = 0; table_index < count;
table_index++)` — which correctly bounds the access. Only bios_parser.c
(v1) has this off-by-one bug.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Code Exists in Stable Trees
The buggy code was introduced in `4562236b3bc0a2` ("drm/amd/dc: Add dc
display driver (v2)") merged in v4.15 (2017). This code exists in
**ALL** active stable trees (5.4, 5.10, 5.15, 6.1, 6.6, 6.12, 7.0,
etc.).

### Step 6.2: Backport Complications
The function has been **unchanged since 2017**. The fix will apply
cleanly to all stable trees without modification.

### Step 6.3: No related fixes already in stable for this specific
issue.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem
- **Path**: drivers/gpu/drm/amd/display — AMD GPU display driver
- **Criticality**: IMPORTANT — AMD GPUs are extremely common in
  desktops, laptops, and servers
- Signed off by subsystem maintainer (Alex Deucher)

### Step 7.2: Subsystem Activity
Actively developed with regular changes. The bios_parser.c file itself
is relatively stable since it handles older BIOS formats.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
All users with AMD GPUs that use the older ATOM v1 BIOS format (pre-Vega
GPUs: Polaris, older GCN). This includes a significant installed base.

### Step 8.2: Trigger Conditions
The bug triggers when the BIOS table has a `bfI2C_LineMux` value equal
to the computed record count. This depends on the specific GPU's
BIOS/VBIOS contents. While not every GPU will trigger this (it requires
a specific boundary condition in the BIOS table), it's entirely
firmware-determined and can't be worked around by users.

### Step 8.3: Failure Mode
When triggered: reads uninitialized/garbage BIOS data for register
indices and shift values, which are then used for hardware register
access. This could cause:
- Incorrect GPIO/I2C configuration → display initialization failure
- Reads of wrong hardware registers → unpredictable behavior
- **Severity**: HIGH (incorrect hardware register access from garbage
  data)

### Step 8.4: Risk-Benefit
- **Benefit**: HIGH — prevents out-of-bounds access in display
  initialization path used by all AMD GPUs with older BIOS format
- **Risk**: VERY LOW — single character change that only tightens a
  bounds check. Cannot introduce regressions.
- **Ratio**: Overwhelmingly favorable

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting:**
- Classic off-by-one out-of-bounds array access — a real bug
- Single character change (`<` → `<=`) — maximally minimal
- Obviously correct — trivially verifiable by reading the code
- Bug exists since v4.15 (2017) — affects all stable trees
- Code is completely unchanged since introduction — will apply cleanly
  everywhere
- Signed off by subsystem maintainer (Alex Deucher)
- Prevents access to uninitialized data used for hardware register
  operations
- No dependencies, completely standalone

**AGAINST backporting:**
- No reported user incidents (but the bug depends on specific BIOS table
  values)
- No Fixes: tag or syzbot report (expected for AUTOSEL candidates)

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** YES — trivially verifiable, signed
   off by maintainer
2. **Fixes a real bug?** YES — out-of-bounds array access
3. **Important issue?** YES — OOB access leading to incorrect hardware
   register operations
4. **Small and contained?** YES — 1 character change in 1 file
5. **No new features/APIs?** Correct — pure bug fix
6. **Can apply to stable?** YES — code unchanged since v4.15, will apply
   cleanly

### Step 9.3: Exception Categories
Not needed — this clearly meets standard stable criteria as a bug fix.

---

## Verification

- [Phase 1] Parsed tags: Signed-off-by Alex Deucher (AMD DRM
  maintainer), author Pengpeng Hou
- [Phase 2] Diff analysis: Single character change `<` to `<=` in bounds
  check at line 1957 of bios_parser.c
- [Phase 2] Verified the OOB: `count` = number of valid records
  (0-indexed), old check passes when index == count, which is one past
  last valid entry
- [Phase 3] git blame: All code in affected function from commit
  4562236b3bc0a2 (Harry Wentland, 2017-09-12, v4.15 initial driver
  import)
- [Phase 3] git log: Function unchanged since 2017, no intermediate
  fixes for same issue
- [Phase 3] Author: Pengpeng Hou has 10+ similar bounds-checking fixes
  in tree (NFC, net, BT, tracing)
- [Phase 5] Callers: `get_gpio_i2c_info()` called via `.get_i2c_info`
  vtable from link_ddc.c (DDC init) and dce_i2c.c (OEM I2C) — display
  initialization paths
- [Phase 5] Verified bios_parser2.c uses `for (table_index = 0;
  table_index < count; ...)` — different approach, not affected
- [Phase 5] Verified ATOM_GPIO_I2C_INFO struct:
  `asGPIO_Info[ATOM_MAX_SUPPORTED_DEVICE]` with
  ATOM_MAX_SUPPORTED_DEVICE=16
- [Phase 6] Code exists unchanged in all stable trees since v4.15 —
  clean apply guaranteed
- [Phase 7] AMD GPU display driver — IMPORTANT subsystem, widely used
  hardware
- [Phase 8] Failure mode: garbage register indices/shifts used for
  hardware access — HIGH severity
- UNVERIFIED: Could not find original mailing list discussion (lore
  blocked by bot protection, b4 dig found nothing). This does not affect
  the decision — the fix is technically obvious.

---

This is a textbook stable backport candidate: a single-character fix for
an off-by-one out-of-bounds array access that has existed since the
driver was introduced in v4.15. The fix is maximally minimal, obviously
correct, signed off by the subsystem maintainer, applies cleanly to all
stable trees, and has zero regression risk.

**YES**

 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
index 73e3c45eeeba6..2c9cf00b22745 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
@@ -1954,7 +1954,7 @@ static enum bp_result get_gpio_i2c_info(struct bios_parser *bp,
 	count = (le16_to_cpu(header->sHeader.usStructureSize)
 			- sizeof(ATOM_COMMON_TABLE_HEADER))
 				/ sizeof(ATOM_GPIO_I2C_ASSIGMENT);
-	if (count < record->sucI2cId.bfI2C_LineMux)
+	if (count <= record->sucI2cId.bfI2C_LineMux)
 		return BP_RESULT_BADBIOSTABLE;
 
 	/* get the GPIO_I2C_INFO */
-- 
2.53.0

[PATCH AUTOSEL 7.0] drm/amdgpu: Handle IH v7_1 reg offset differences

[Sasha Levin]

From: Hawking Zhang <Hawking.Zhang@amd.com>

[ Upstream commit 41c61e60f82d55e9a3a3f3f04d192d732230a91c ]

IH v7_1 changes the offsets of some registers relative to
IH v7_0. Introduce IH v7_1-specific register access

Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Connection lost, reconnecting (attempt 1)...
Retry attempt 1...
Now let me compile the final analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: `drm/amdgpu` (AMD GPU driver, IH = Interrupt Handler)
- **Action verb**: "Handle" - implies addressing a functional issue
- **Summary**: Addresses register offset differences between IH v7.0 and
  IH v7.1 hardware IP versions

Record: [drm/amdgpu] [Handle] [Fix wrong register offsets for IH v7.1
hardware]

### Step 1.2: Tags
- Signed-off-by: Hawking Zhang (AMD GPU architect/contributor)
- Reviewed-by: Lijo Lazar (AMD GPU developer)
- Signed-off-by: Alex Deucher (AMD GPU subsystem maintainer)
- No Fixes: tag, no Reported-by, no Cc: stable - all expected for
  candidate evaluation.

Record: Standard AMD GPU driver patch flow. Reviewed by subsystem
contributor, signed off by maintainer.

### Step 1.3: Commit Body
The body explains: "IH v7_1 changes the offsets of some registers
relative to IH v7_0." This states factually that register offsets differ
between hardware versions. "Introduce IH v7_1-specific register access"
means the fix adds conditional paths.

Record: The bug is that IH v7.1 hardware has different register offsets
for certain registers, but the driver uses v7.0 offsets for all
versions, leading to wrong register accesses.

### Step 1.4: Hidden Bug Fix Detection
This IS a hidden bug fix. The phrase "Handle... differences" understates
the issue: without this change, the driver reads/writes WRONG register
offsets on IH v7.1 hardware. This is a functional correctness bug.

Record: Yes, this is a hidden bug fix disguised as enablement.

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files**: `drivers/gpu/drm/amd/amdgpu/ih_v7_0.c` (+22 lines net)
- **Functions modified**: `ih_v7_0_irq_init()`
- **Scope**: Single-file, single-function, surgical fix

### Step 2.2: Code Flow Change
The diff modifies `ih_v7_0_irq_init()` in three places:

1. **IH_CHICKEN register** (lines 321-324): Before: always uses
   `regIH_CHICKEN` (0x018a from v7.0 header). After: checks IP version;
   uses 0x0129 for v7.1, 0x018a for v7.0.

2. **IH_RING1_CLIENT_CFG_INDEX** (lines 361-363): Before: always uses
   `regIH_RING1_CLIENT_CFG_INDEX` (0x0183). After: uses 0x0122 for v7.1.

3. **IH_RING1_CLIENT_CFG_DATA** (lines 365-371): Before: always uses
   `regIH_RING1_CLIENT_CFG_DATA` (0x0184). After: uses 0x0123 for v7.1.

Six local `#define` constants are added for the v7.1 offsets.

### Step 2.3: Bug Mechanism
**Category**: Hardware register access correctness bug

I verified the register offsets from the actual header files:

**osssys_7_0_0_offset.h**:
- `regIH_CHICKEN` = 0x018a
- `regIH_RING1_CLIENT_CFG_INDEX` = 0x0183
- `regIH_RING1_CLIENT_CFG_DATA` = 0x0184

**osssys_7_1_0_offset.h**:
- `regIH_CHICKEN` = 0x0129
- `regIH_RING1_CLIENT_CFG_INDEX` = 0x0122
- `regIH_RING1_CLIENT_CFG_DATA` = 0x0123

The offsets differ significantly (e.g., IH_CHICKEN is 0x61 dwords
apart). Since `ih_v7_0.c` only includes the v7.0 header, on v7.1
hardware it reads/writes completely wrong registers.

### Step 2.4: Fix Quality
- **Obviously correct**: Yes - version check + correct v7.1 offsets
  verified against official header
- **Minimal/surgical**: Yes - only the three affected registers are
  touched
- **Regression risk**: Very low - only changes behavior for
  IP_VERSION(7,1,0); v7.0 paths unchanged
- **Red flags**: None

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
The buggy `RREG32_SOC15(OSSSYS, 0, regIH_CHICKEN)` at line 321 was
introduced by `12443fc53e7d7` (Likun Gao, 2023 - initial ih_v7_0
support). The IH_RING1 client config lines (359-371) were added by
`f0c6b79bfc921` (Sunil Khatri, July 2024).

### Step 3.2: Fixes Tag
No Fixes: tag present. The underlying issue is that `692c70f4d8024`
("drm/amdgpu: Use ih v7_0 ip block for ih v7_1") claimed v7.1 could
share the v7.0 implementation, but didn't account for register offset
differences. This commit IS in the stable tree.

### Step 3.3: File History
20+ commits to ih_v7_0.c, mostly API refactoring. The v7.1-specific code
(retry CAM) was added by `e06d194201189` which IS in this tree.

### Step 3.4: Author
Hawking Zhang is a principal AMD GPU architect and frequent contributor,
also added the osssys v7.1 headers.

### Step 3.5: Dependencies
No dependencies. The commit is self-contained - it adds local #defines
rather than including the v7.1 header (avoiding symbol clashes).

## PHASE 4: MAILING LIST RESEARCH

Could not find the specific patch thread on lore.kernel.org (Anubis
anti-scraping protection blocked search). Web search also did not find
the exact patch. The "Consolidate register access methods" series by
Lijo Lazar (Jan 2026) appears to be a follow-up refactoring.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
`ih_v7_0_irq_init()` is the only function modified.

### Step 5.2: Callers
`ih_v7_0_irq_init()` is called from:
- `ih_v7_0_hw_init()` -> called during device load
- `ih_v7_0_resume()` -> called during system resume

These are critical initialization paths that run every time the GPU is
initialized or resumed.

### Step 5.4: Reachability
Absolutely reachable - runs on every device init and resume for any GPU
using IH v7.x.

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable
YES - both the code and the IH v7.1 hardware recognition
(`amdgpu_discovery.c` line 2110: `case IP_VERSION(7, 1, 0)`) exist in
this 7.0 tree. The v7.1-specific retry CAM code (commit `e06d194201189`)
is also present.

### Step 6.2: Backport Complications
The patch should apply cleanly - the file in the stable tree matches the
pre-image of the diff exactly. The current code at lines 303-402 matches
what the diff expects.

### Step 6.3: Related Fixes
No related fix for the same issue already in stable.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem Criticality
`drm/amdgpu` - IMPORTANT. AMD GPUs are very widely used. IH (Interrupt
Handler) is critical for GPU interrupt delivery.

### Step 7.2: Activity
Very active subsystem with frequent changes.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
Users with IH v7.1 GPUs (specific AMD GPU generation). These GPUs are
detected and loaded by the driver in the 7.0 stable tree.

### Step 8.2: Trigger Conditions
Every GPU initialization and every system resume. 100% reproducible on
affected hardware.

### Step 8.3: Failure Mode Severity
Without this fix on IH v7.1 hardware:
- **IH_CHICKEN wrong**: Bus address mode for IH not configured ->
  potential firmware load path issues
- **IH_RING1_CLIENT_CFG wrong**: Interrupt redirection to ring 1 broken
  for dGPUs -> interrupt handling incomplete
- **Wrong register writes**: Writing to offset 0x018a instead of 0x0129
  corrupts whatever register is actually at 0x018a
- Severity: **HIGH** - broken interrupt initialization on affected GPUs

### Step 8.4: Risk-Benefit Ratio
- **Benefit**: HIGH - makes IH v7.1 GPUs work correctly with proper
  interrupt handling
- **Risk**: VERY LOW - only changes behavior for IP_VERSION(7,1,0), all
  v7.0 paths unchanged
- **Ratio**: Strongly favorable

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting**:
- Fixes wrong register access on hardware already supported in stable
  (v7.1 IP recognized, block loaded)
- Three registers accessed at completely wrong offsets (0x018a vs
  0x0129, etc.)
- Wrong register writes can corrupt hardware state and break interrupt
  handling
- Every GPU init/resume triggers the bug on affected hardware
- Self-contained single-file fix
- Reviewed by AMD developer, signed off by AMD maintainer
- Low regression risk (v7.0 hardware unaffected)
- Fix quality is high: correct offsets verified against official header
  file

**AGAINST backporting**:
- Moderate size (~22 lines, 6 #defines + conditional logic)
- Commit message reads more like enablement than a bug fix
- No Reported-by or syzbot (hardware may not yet be widely deployed)
- Could be considered part of ongoing hardware bring-up

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** - offsets verified against v7.1
   header
2. Fixes a real bug? **YES** - wrong register addresses on v7.1 hardware
3. Important issue? **YES** - broken interrupt initialization, potential
   register corruption
4. Small and contained? **YES** - single file, single function, ~22
   lines
5. No new features? **YES** - fixes existing hardware support
6. Can apply to stable? **YES** - file matches pre-image exactly

### Step 9.3: Exception Categories
This is a **hardware workaround/quirk** for register offset differences
- this exception category applies.

## Verification

- [Phase 1] Parsed tags: Reviewed-by: Lijo Lazar, Signed-off-by: Hawking
  Zhang + Alex Deucher
- [Phase 2] Diff analysis: adds #defines for 3 v7.1 register offsets +
  conditional selection in ih_v7_0_irq_init()
- [Phase 2] Verified v7.0 offsets: IH_CHICKEN=0x018a, CFG_INDEX=0x0183,
  CFG_DATA=0x0184 (from osssys_7_0_0_offset.h)
- [Phase 2] Verified v7.1 offsets: IH_CHICKEN=0x0129, CFG_INDEX=0x0122,
  CFG_DATA=0x0123 (from osssys_7_1_0_offset.h)
- [Phase 2] Confirmed #defines in patch match v7.1 header values exactly
- [Phase 2] Confirmed all other IH registers (RB_BASE, RB_CNTL, etc.)
  have SAME offsets in v7.0 and v7.1 - only these three differ
- [Phase 3] git blame: regIH_CHICKEN usage introduced by 12443fc53e7d7
  (initial ih_v7_0, 2023); client CFG added by f0c6b79bfc921 (2024)
- [Phase 3] git show 692c70f4d8024: confirmed this commit added
  IP_VERSION(7,1,0) mapping to ih_v7_0_ip_block in discovery
- [Phase 3] git show e06d194201189: confirmed v7.1-specific CAM code
  exists in stable tree
- [Phase 5] ih_v7_0_irq_init() called from hw_init (device load) and
  resume - critical paths
- [Phase 6] Confirmed IP_VERSION(7,1,0) recognized in amdgpu_discovery.c
  line 2110 of this tree
- [Phase 6] Confirmed osssys_7_1_0_offset.h exists in this tree (commit
  755b5591739cc)
- [Phase 6] File matches pre-image of diff exactly - clean apply
  expected
- [Phase 6] RREG32_SOC15 macro verified: uses
  `adev->reg_offset[ip_HWIP][inst][reg_BASE_IDX] + reg` - the `reg`
  value comes from the included header (7_0_0)
- UNVERIFIED: Could not access lore.kernel.org to read patch discussion
  (Anubis protection)
- UNVERIFIED: Which specific GPU models use IH v7.1 (but confirmed it IS
  recognized in this tree)

**YES**

 drivers/gpu/drm/amd/amdgpu/ih_v7_0.c | 36 ++++++++++++++++++++++------
 1 file changed, 29 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/ih_v7_0.c b/drivers/gpu/drm/amd/amdgpu/ih_v7_0.c
index 451828bf583e4..1fbe904f4223b 100644
--- a/drivers/gpu/drm/amd/amdgpu/ih_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/ih_v7_0.c
@@ -289,6 +289,13 @@ static uint32_t ih_v7_0_setup_retry_doorbell(u32 doorbell_index)
 	return val;
 }
 
+#define regIH_RING1_CLIENT_CFG_INDEX_V7_1             0x122
+#define regIH_RING1_CLIENT_CFG_INDEX_V7_1_BASE_IDX    0
+#define regIH_RING1_CLIENT_CFG_DATA_V7_1              0x123
+#define regIH_RING1_CLIENT_CFG_DATA_V7_1_BASE_IDX     0
+#define regIH_CHICKEN_V7_1                            0x129
+#define regIH_CHICKEN_V7_1_BASE_IDX                   0
+
 /**
  * ih_v7_0_irq_init - init and enable the interrupt ring
  *
@@ -307,6 +314,7 @@ static int ih_v7_0_irq_init(struct amdgpu_device *adev)
 	u32 tmp;
 	int ret;
 	int i;
+	u32 reg_addr;
 
 	/* disable irqs */
 	ret = ih_v7_0_toggle_interrupts(adev, false);
@@ -318,10 +326,15 @@ static int ih_v7_0_irq_init(struct amdgpu_device *adev)
 	if (unlikely((adev->firmware.load_type == AMDGPU_FW_LOAD_DIRECT) ||
 		     (adev->firmware.load_type == AMDGPU_FW_LOAD_RLC_BACKDOOR_AUTO))) {
 		if (ih[0]->use_bus_addr) {
-			ih_chicken = RREG32_SOC15(OSSSYS, 0, regIH_CHICKEN);
+			if (amdgpu_ip_version(adev, OSSSYS_HWIP, 0) == IP_VERSION(7, 1, 0))
+				reg_addr = SOC15_REG_OFFSET(OSSSYS, 0, regIH_CHICKEN_V7_1);
+			else
+				reg_addr = SOC15_REG_OFFSET(OSSSYS, 0, regIH_CHICKEN);
+			ih_chicken = RREG32(reg_addr);
+			/* The reg fields definitions are identical in ih v7_0 and ih v7_1 */
 			ih_chicken = REG_SET_FIELD(ih_chicken,
 					IH_CHICKEN, MC_SPACE_GPA_ENABLE, 1);
-			WREG32_SOC15(OSSSYS, 0, regIH_CHICKEN, ih_chicken);
+			WREG32(reg_addr, ih_chicken);
 		}
 	}
 
@@ -358,17 +371,26 @@ static int ih_v7_0_irq_init(struct amdgpu_device *adev)
 
 	/* Redirect the interrupts to IH RB1 for dGPU */
 	if (adev->irq.ih1.ring_size) {
-		tmp = RREG32_SOC15(OSSSYS, 0, regIH_RING1_CLIENT_CFG_INDEX);
+		if (amdgpu_ip_version(adev, OSSSYS_HWIP, 0) == IP_VERSION(7, 1, 0))
+			reg_addr = SOC15_REG_OFFSET(OSSSYS, 0, regIH_RING1_CLIENT_CFG_INDEX_V7_1);
+		else
+			reg_addr = SOC15_REG_OFFSET(OSSSYS, 0, regIH_RING1_CLIENT_CFG_INDEX);
+		tmp = RREG32(reg_addr);
+		/* The reg fields definitions are identical in ih v7_0 and ih v7_1 */
 		tmp = REG_SET_FIELD(tmp, IH_RING1_CLIENT_CFG_INDEX, INDEX, 0);
-		WREG32_SOC15(OSSSYS, 0, regIH_RING1_CLIENT_CFG_INDEX, tmp);
+		WREG32(reg_addr, tmp);
 
-		tmp = RREG32_SOC15(OSSSYS, 0, regIH_RING1_CLIENT_CFG_DATA);
+		if (amdgpu_ip_version(adev, OSSSYS_HWIP, 0) == IP_VERSION(7, 1, 0))
+			reg_addr = SOC15_REG_OFFSET(OSSSYS, 0, regIH_RING1_CLIENT_CFG_DATA_V7_1);
+		else
+			reg_addr = SOC15_REG_OFFSET(OSSSYS, 0, regIH_RING1_CLIENT_CFG_DATA);
+		tmp = RREG32(reg_addr);
+		/* The reg fields definitions are identical in ih v7_0 and ih v7_1 */
 		tmp = REG_SET_FIELD(tmp, IH_RING1_CLIENT_CFG_DATA, CLIENT_ID, 0xa);
 		tmp = REG_SET_FIELD(tmp, IH_RING1_CLIENT_CFG_DATA, SOURCE_ID, 0x0);
 		tmp = REG_SET_FIELD(tmp, IH_RING1_CLIENT_CFG_DATA,
 				    SOURCE_ID_MATCH_ENABLE, 0x1);
-
-		WREG32_SOC15(OSSSYS, 0, regIH_RING1_CLIENT_CFG_DATA, tmp);
+		WREG32(reg_addr, tmp);
 	}
 
 	pci_set_master(adev->pdev);
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] drm/amdgpu/vcn4.0.3: gate per-queue reset by PSP SOS program version

[Sasha Levin]

From: Jesse Zhang <Jesse.Zhang@amd.com>

[ Upstream commit 16df395a55c635649dd3cf41d61bd685d3fd7a98 ]

Add a PSP SOS firmware compatibility check before enabling VCN per-queue
reset on vcn_v4_0_3.

Per review, program check is sufficient: when PSP SOS program is 0x01,
require fw version >= 0x0036015f; otherwise allow per-queue reset.

Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Suggested-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Jesse Zhang <Jesse.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: PARSE THE SUBJECT LINE**
- Subsystem prefix: `drm/amdgpu/vcn4.0.3`
- Action verb: "gate" (restrict/conditionally enable)
- Summary: Gate VCN per-queue reset feature behind a PSP SOS firmware
  version check.

Record: [drm/amdgpu/vcn4.0.3] [gate] [Add firmware compatibility check
before enabling per-queue reset]

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
- `Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>` - AMD GPU firmware/IP
  maintainer
- `Suggested-by: Lijo Lazar <lijo.lazar@amd.com>` - The approach was
  suggested by the reviewer
- `Signed-off-by: Jesse Zhang <Jesse.zhang@amd.com>` - Author
- `Signed-off-by: Alex Deucher <alexander.deucher@amd.com>` - AMD DRM
  subsystem maintainer
- No Fixes: tag (expected for autosel candidates)
- No Cc: stable tag (expected)
- No Reported-by tag

Record: Reviewed and suggested by Lijo Lazar (AMD), committed by Alex
Deucher (subsystem maintainer). No explicit bug reporter or syzbot
involvement.

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
The commit explains that PSP SOS firmware compatibility must be checked
before enabling VCN per-queue reset. Specifically: when PSP SOS program
is 0x01, firmware version must be >= 0x0036015f. Otherwise (other
programs), per-queue reset is allowed. This prevents enabling a reset
path that the firmware doesn't support.

Record: Bug: per-queue reset enabled without firmware version gating,
leading to attempted resets on firmware that doesn't support it.
Symptom: failed per-queue resets that fall back to full GPU reset. Root
cause: missing firmware capability check.

**Step 1.4: DETECT HIDDEN BUG FIXES**
This is a firmware compatibility fix. "Gate" means "restrict to
compatible configurations." Without it, per-queue reset is attempted on
incompatible firmware, which fails. This is a real bug fix - enabling a
feature on hardware/firmware that doesn't support it.

Record: Yes, this is a real bug fix - it prevents incorrect feature
enablement on incompatible firmware.

---

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

**Step 2.1: INVENTORY THE CHANGES**
- File: `drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c` (+18, -1)
- New function: `vcn_v4_0_3_is_psp_fw_reset_supported()` (15 lines)
- Modified function: `vcn_v4_0_3_late_init()` (1 line condition change)
- Scope: Single-file surgical fix

Record: 1 file changed, 18 insertions, 1 deletion. Functions: new
`vcn_v4_0_3_is_psp_fw_reset_supported()`, modified
`vcn_v4_0_3_late_init()`. Single-file surgical fix.

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
- **Before**: `vcn_v4_0_3_late_init()` checks
  `amdgpu_dpm_reset_vcn_is_supported(adev) && !amdgpu_sriov_vf(adev)` to
  enable per-queue reset. No firmware version check.
- **After**: Same check, but now also calls
  `vcn_v4_0_3_is_psp_fw_reset_supported(adev)` which extracts the PSP
  program version from firmware version field and requires version >=
  0x0036015f for program 0x01.
- This is an initialization-time check; it only runs once during
  `late_init`.

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Category: (h) Hardware workaround / firmware compatibility fix.
The new function extracts `pgm = (fw_ver >> 8) & 0xFF` and for program
1, requires `fw_ver >= 0x0036015f`. This follows the exact same pattern
as `vcn_v5_0_1` which checks `adev->psp.sos.fw_version >= 0x00450025`.

Without this check, `AMDGPU_RESET_TYPE_PER_QUEUE` is set on systems
where PSP firmware can't handle it. When a VCN timeout occurs,
`amdgpu_job_timedout()` -> `amdgpu_ring_reset()` ->
`vcn_v4_0_3_ring_reset()` -> `amdgpu_dpm_reset_vcn()` is called. If PSP
can't handle it, the reset fails, the driver logs "VCN reset fail" and
falls through to a full GPU reset.

Record: Firmware compatibility fix. Missing version check causes per-
queue reset to be attempted on incompatible firmware, leading to reset
failures and unnecessary full GPU resets.

**Step 2.4: ASSESS THE FIX QUALITY**
- Obviously correct: simple version comparison
- Minimal and surgical: 18 lines, single file, follows established
  pattern from vcn_v5_0_1
- Regression risk: extremely low. Worst case: per-queue reset disabled
  when it should be enabled (fallback to full GPU reset, which was the
  old behavior anyway)
- No API changes, no lock changes, no data structure changes

Record: Fix quality: excellent. Follows established pattern. Regression
risk: very low.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: BLAME THE CHANGED LINES**
- `vcn_v4_0_3_late_init()` was introduced by commit 655d6403ad143 (Jesse
  Zhang, 2025-08-13), first in v6.18-rc1
- The `!amdgpu_sriov_vf(adev)` condition was added by c156c7f27ecdb
  (Shikang Fan, 2025-11-19), also in v6.18

Record: Buggy code (missing firmware check) was introduced in v6.18-rc1
with commit 655d6403ad143.

**Step 3.2: FOLLOW THE FIXES TAG**
No Fixes: tag present. This is expected for autosel candidates.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Between the late_init introduction (655d6403ad143) and this fix, the
file has had several changes including rework of reset handling
(d25c67fd9d6fe), DPG pause mode handling (de93bc353361f), and JPEG ring
test ordering fix (91544c45fa6a1). The fix applies cleanly on top of the
current state with the sriov check.

Record: The fix is standalone, no prerequisites beyond the existing
late_init function (which is already in the tree).

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Jesse Zhang is a regular AMD GPU driver contributor with many commits in
the amdgpu subsystem, including the original late_init callback, SDMA
fixes, and queue reset work.

Record: Author is a regular AMD driver contributor, familiar with the
subsystem.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
The fix depends only on `vcn_v4_0_3_late_init()` existing (commit
655d6403ad143) and access to `adev->psp.sos.fw_version`. Both exist in
the current tree. The fix is self-contained.

Record: No additional dependencies. Applies standalone.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
b4 dig could not find the patch (possibly due to the AMD internal
submission process), but the mail-archive.com search found both V1 and
V2.

- V1: `[PATCH] drm/amdgpu/vcn4.0.3: gate VCN reset on PSP FW for MP0
  13.0.6` - included an IP version switch (13.0.6 specific)
- V2: `[PATCH V2] drm/amdgpu/vcn4.0.3: gate per-queue reset by PSP SOS
  program version` - simplified per Lijo's review feedback

**Step 4.2: CHECK WHO REVIEWED THE PATCH**
Lijo Lazar (AMD IP/firmware expert) reviewed both versions and gave
Reviewed-by on V2. He suggested the simplification (program check alone
is sufficient). Alex Deucher (AMD DRM subsystem maintainer) committed
it.

Record: Thoroughly reviewed by AMD maintainers. V1 was revised per
feedback.

**Step 4.3: SEARCH FOR THE BUG REPORT**
No explicit bug report link. The ticket reference FWDEV-159155 is an
AMD-internal tracker. Lijo noted in review that internal ticket
references shouldn't be in comments.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
This is a standalone single patch, not part of a series. VCN v5.0.1
already had the same pattern (firmware version gating) from commit
5886090032ec8.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
Could not access lore.kernel.org directly due to bot protection. No
evidence of explicit stable nomination found in the mail-archive
discussion.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: IDENTIFY KEY FUNCTIONS**
- New: `vcn_v4_0_3_is_psp_fw_reset_supported()` - called only from
  `vcn_v4_0_3_late_init()`
- Modified: `vcn_v4_0_3_late_init()` - called during driver
  initialization

**Step 5.2: TRACE CALLERS**
`vcn_v4_0_3_late_init` is registered as the `.late_init` callback in the
IP function table. It's called once during device initialization by the
amdgpu IP block management code.

**Step 5.3-5.4: DOWNSTREAM IMPACT**
If `AMDGPU_RESET_TYPE_PER_QUEUE` is incorrectly set,
`amdgpu_job_timedout()` (amdgpu_job.c:134-155) will attempt per-queue
reset via `vcn_v4_0_3_ring_reset()` which calls
`amdgpu_dpm_reset_vcn()`. If firmware doesn't support it, this fails,
and the driver falls through to a full GPU reset - a much more
disruptive event that resets all GPU engines.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
VCN v5.0.1 already has the same firmware version gating pattern
(`vcn_v5_0_1_late_init`, line 125). GFX v11, v12, and SDMA v4.4.2 also
gate per-queue reset behind firmware version checks. This is a well-
established pattern.

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

**Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?**
The `vcn_v4_0_3_late_init()` function (with per-queue reset enablement
but without firmware version check) was introduced in v6.18-rc1 (commit
655d6403ad143). It exists in stable trees 6.18.y and newer. The VCN per-
queue reset implementation itself was in v6.16+, but the late_init
enablement path is the specific code this fixes.

Record: Buggy code exists in 6.18.y and newer stable trees.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
The patch applies directly against the current state of `vcn_v4_0_3.c`.
For 6.18.y, the patch should apply cleanly as the `vcn_v4_0_3_late_init`
function with the same context lines exists there.

Record: Expected clean apply to 6.18.y+.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE**
No related firmware version check fix for vcn_v4_0_3 has been applied to
stable. The sriov check (c156c7f27ecdb) was cherry-picked to stable with
Cc: stable tag, but that's a different fix.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
- Subsystem: `drivers/gpu/drm/amd/amdgpu` - AMD GPU driver
- Criticality: IMPORTANT - AMD GPUs are widely used in servers (MI-
  series) and workstations

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Very actively developed. VCN v4.0.3 specifically is for data center GPUs
(Instinct series with multiple VCN instances).

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: DETERMINE WHO IS AFFECTED**
Users with AMD GPUs that use VCN v4.0.3 (data center/MI-series GPUs)
running PSP SOS firmware program 0x01 with version < 0x0036015f.

Record: Driver-specific, but for important data center hardware.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Trigger: A VCN (video encode/decode) job times out, causing the
scheduler to attempt a per-queue reset. With incompatible firmware, the
per-queue reset fails, forcing a full GPU reset.

Record: Triggered by VCN job timeout (can happen during normal video
workloads). The per-queue reset attempt itself is the trigger for the
bug.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
- Without fix: Failed per-queue reset → full GPU reset (disrupts ALL GPU
  workloads, not just VCN)
- A full GPU reset on a data center GPU is highly disruptive
- Severity: HIGH (unnecessary disruptive full GPU reset instead of
  contained per-queue reset)

Record: Failure mode: unnecessary full GPU reset instead of graceful
fallback to non-per-queue behavior. Severity: HIGH for data center use.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
- BENEFIT: Prevents failed per-queue resets and unnecessary full GPU
  resets on systems with older firmware
- RISK: Very low. 18 lines, single file, initialization-only code,
  follows established pattern. Worst case: per-queue reset incorrectly
  disabled → falls back to full GPU reset (same as not having per-queue
  reset at all, the previous behavior)

Record: High benefit, very low risk.

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: COMPILE THE EVIDENCE**

FOR backporting:
- Fixes a real firmware compatibility bug (per-queue reset attempted on
  unsupported firmware)
- Small (18 lines), surgical, single-file change
- Follows established pattern from vcn_v5_0_1
- Reviewed by AMD maintainer Lijo Lazar, committed by subsystem
  maintainer Alex Deucher
- Went through V1→V2 revision with reviewer feedback
- Prevents unnecessary full GPU resets on data center hardware
- Very low regression risk
- Self-contained, no dependencies

AGAINST backporting:
- No explicit Cc: stable (expected for autosel)
- No Fixes: tag pointing to specific broken commit
- No user-reported bug (AMD internal tracking reference FWDEV-159155)
- Could be viewed as "hardening" rather than fixing a crash
- Relatively new code (v6.18+), limited stable tree exposure

UNRESOLVED:
- Could not access lore.kernel.org directly to check for stable-specific
  discussions
- Don't know how many users have the specific old firmware configuration

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **Yes** - simple version comparison,
   reviewed by AMD maintainer
2. Fixes a real bug? **Yes** - prevents failed per-queue resets with
   incompatible firmware
3. Important issue? **Yes** - prevents unnecessary full GPU resets (HIGH
   severity for data center)
4. Small and contained? **Yes** - 18 lines, 1 file
5. No new features or APIs? **Correct** - gates an existing feature
6. Can apply to stable trees? **Yes** - should apply cleanly to 6.18.y+

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
This could be classified as a hardware/firmware quirk/workaround -
gating feature enablement based on firmware version. These are typically
YES for stable.

**Step 9.4: MAKE YOUR DECISION**
This is a firmware compatibility fix that prevents the driver from
enabling a reset path on firmware that doesn't support it. Without it,
VCN job timeouts on affected systems lead to failed per-queue resets and
unnecessary full GPU resets. The fix is small, surgical, well-reviewed,
follows an established pattern, and has very low regression risk.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Lijo Lazar, Suggested-by Lijo
  Lazar, Signed-off-by Jesse Zhang and Alex Deucher. No Fixes: or Cc:
  stable (expected).
- [Phase 2] Diff analysis: 18 lines added (new helper + condition
  change), single file `vcn_v4_0_3.c`.
- [Phase 3] git blame: `vcn_v4_0_3_late_init()` introduced by commit
  655d6403ad143 in v6.18-rc1. Sriov check added by c156c7f27ecdb in
  v6.18.
- [Phase 3] git tag --contains: late_init commit first in v6.18, queue
  reset impl in v6.16, this PSP check in v7.0.
- [Phase 3] git log author: Jesse Zhang is a regular AMD GPU driver
  contributor.
- [Phase 4] mail-archive.com: Found V1 and V2 submissions. V1 had IP
  version switch, V2 simplified per Lijo's review ("The program check
  itself should be good enough").
- [Phase 4] Lijo Lazar gave Reviewed-by on V2, noted internal ticket
  reference should be removed.
- [Phase 5] `vcn_v4_0_3_late_init()` is called once during
  initialization; affects `AMDGPU_RESET_TYPE_PER_QUEUE` flag which gates
  reset behavior in `amdgpu_job_timedout()`.
- [Phase 5] vcn_v5_0_1 already has same firmware version gating pattern
  at line 125.
- [Phase 6] Buggy code present in 6.18.y+ stable trees. Patch expected
  to apply cleanly.
- [Phase 8] Failure mode: failed per-queue reset → full GPU reset.
  Severity: HIGH for data center.
- UNVERIFIED: Could not access lore.kernel.org directly (bot
  protection). Used mail-archive.com as alternate source for discussion.
- UNVERIFIED: Exact population of affected users with old firmware is
  unknown, but AMD filed internal tracking ticket FWDEV-159155.

**YES**

 drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
index e78526a4e521e..ff3013b97abd1 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
@@ -134,6 +134,21 @@ static int vcn_v4_0_3_early_init(struct amdgpu_ip_block *ip_block)
 	return 0;
 }
 
+static bool vcn_v4_0_3_is_psp_fw_reset_supported(struct amdgpu_device *adev)
+{
+	uint32_t fw_ver = adev->psp.sos.fw_version;
+	uint32_t pgm = (fw_ver >> 8) & 0xFF;
+
+	/*
+	 * FWDEV-159155: PSP SOS FW must be >= 0x0036015f for program 0x01
+	 * before enabling VCN per-queue reset.
+	 */
+	if (pgm == 1)
+		return fw_ver >= 0x0036015f;
+
+	return true;
+}
+
 static int vcn_v4_0_3_late_init(struct amdgpu_ip_block *ip_block)
 {
 	struct amdgpu_device *adev = ip_block->adev;
@@ -141,7 +156,9 @@ static int vcn_v4_0_3_late_init(struct amdgpu_ip_block *ip_block)
 	adev->vcn.supported_reset =
 		amdgpu_get_soft_full_reset_mask(&adev->vcn.inst[0].ring_enc[0]);
 
-	if (amdgpu_dpm_reset_vcn_is_supported(adev) && !amdgpu_sriov_vf(adev))
+	if (amdgpu_dpm_reset_vcn_is_supported(adev) &&
+	    vcn_v4_0_3_is_psp_fw_reset_supported(adev) &&
+	    !amdgpu_sriov_vf(adev))
 		adev->vcn.supported_reset |= AMDGPU_RESET_TYPE_PER_QUEUE;
 
 	return 0;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] drm/amdgpu: fix amdgpu_userq_evict

[Sasha Levin]

From: Christian König <christian.koenig@amd.com>

[ Upstream commit 98dc529a27c57e184ab47453993ba9cfcfcec0ca ]

Canceling the resume worker synchonized can deadlock because it can in
turn wait for the eviction worker through the userq_mutex.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Sunil Khatri <sunil.khatri@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a complete analysis. Let me
compile the findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `drm/amdgpu` (AMD GPU DRM driver)
- Action verb: "fix"
- Summary: Fix deadlock in `amdgpu_userq_evict` function
- Record: [drm/amdgpu] [fix] [deadlock in userqueue eviction path]

**Step 1.2: Tags**
- Signed-off-by: Christian König (author, AMD's senior DRM/GPU
  maintainer)
- Reviewed-by: Alex Deucher (AMD's kernel graphics lead maintainer)
- Reviewed-by: Sunil Khatri
- Signed-off-by: Alex Deucher (committer)
- No Fixes: tag (expected - that's why manual review is needed)
- No Cc: stable (expected)
- Record: Author is subsystem maintainer. Two Reviewed-by tags from AMD
  developers. Strong quality signal.

**Step 1.3: Commit Body**
- Bug: Canceling the resume worker synchronously
  (`cancel_delayed_work_sync`) can deadlock because the resume worker
  waits for the eviction worker via `userq_mutex`.
- Record: Classic AB-BA deadlock between suspend_worker and
  resume_worker via `userq_mutex`.

**Step 1.4: Hidden Bug Fix Detection**
- This is explicitly labeled "fix" and describes a deadlock. Not hidden
  at all.
- Record: Obvious deadlock fix.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c`
- Lines removed: ~6, lines added: ~2 (net -4 lines)
- Function modified: `amdgpu_userq_evict()`
- Scope: single-file surgical fix in one function
- Record: Very small, contained change.

**Step 2.2: Code Flow Change**

BEFORE:
```c
if (evf_mgr->fd_closing) {
    cancel_delayed_work_sync(&uq_mgr->resume_work);
    return;
}
schedule_delayed_work(&uq_mgr->resume_work, 0);
```

AFTER:
```c
if (!evf_mgr->fd_closing)
    schedule_delayed_work(&uq_mgr->resume_work, 0);
```

Before: When `fd_closing`, synchronously cancel any pending resume work
and return. Otherwise, schedule resume work.
After: Simply don't schedule resume work when `fd_closing`. No
synchronous cancel.

**Step 2.3: Bug Mechanism**

This is a **deadlock** fix. The verified call chain:

1. `amdgpu_eviction_fence_suspend_worker()` acquires
   `uq_mgr->userq_mutex` (line 110 in `amdgpu_eviction_fence.c`), then
   calls `amdgpu_userq_evict()` (line 119)
2. `amdgpu_userq_evict()` calls
   `cancel_delayed_work_sync(&uq_mgr->resume_work)` when `fd_closing` -
   this waits for resume_work to finish
3. `amdgpu_userq_restore_worker()` (the resume_work callback) first
   calls `flush_delayed_work(&fpriv->evf_mgr.suspend_work)` (line 1277),
   which waits for the suspend_worker, then tries to acquire
   `userq_mutex` (line 1279)

Result: suspend_worker holds `userq_mutex` and waits for resume_worker;
resume_worker either flushes suspend_worker (direct circular wait) or
waits for `userq_mutex` (held by suspend_worker). Classic deadlock.

Record: [Deadlock] [suspend_worker holds userq_mutex ->
cancel_delayed_work_sync waits for resume_worker -> resume_worker
flushes suspend_worker or waits for userq_mutex = DEADLOCK]

**Step 2.4: Fix Quality**
- Obviously correct: Removing the `cancel_delayed_work_sync` eliminates
  the deadlock
- Minimal/surgical: Only removes the dangerous synchronous cancel, keeps
  the logic of not resuming when fd is closing
- Regression risk: Very low. The only concern would be if a stale
  resume_work runs after fd_closing, but other cleanup paths
  (`amdgpu_userq_destroy` at line 632 does `cancel_delayed_work_sync`
  safely before taking mutex) handle this properly.
- Record: High quality fix. No regression risk.

---

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
- The buggy `cancel_delayed_work_sync` in `amdgpu_userq_evict` was
  introduced by commit `f10eb185ad0552` (Arvind Yadav, 2025-05-07, "Fix
  NULL dereference in amdgpu_userq_restore_worker"), though the original
  `fd_closing` branch was from `44cfdf368fb72c` (Shashank Sharma,
  2024-11-20, "resume gfx userqueues").
- Record: Buggy code introduced in the v6.16 development cycle.

**Step 3.2:** No Fixes: tag to follow.

**Step 3.3: Related Changes**
- Commit `648a0dc0d78c3` fixed a different deadlock in the same file
  (mutex ordering between `adev->userq_mutex` and `uqm->userq_mutex`)
- Record: There have been multiple deadlock fixes in this subsystem,
  indicating active locking issues being resolved.

**Step 3.4: Author**
- Christian König is one of the most senior AMD DRM kernel developers
  and a core maintainer of the AMDGPU driver.
- Record: Author is THE subsystem expert. Very high trust signal.

**Step 3.5: Dependencies**
- The fix is self-contained and standalone. It modifies one conditional
  block in one function.
- Record: No dependencies. Clean standalone fix.

---

## PHASE 4: MAILING LIST

- b4 dig could not find the fix commit directly (it appears to be very
  recent, possibly not yet indexed)
- lore.kernel.org search was blocked by anti-scraping protection
- Record: Could not verify mailing list discussion, but the commit has
  two Reviewed-by tags confirming peer review.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions modified**
- Only `amdgpu_userq_evict()` is modified.

**Step 5.2: Callers**
- `amdgpu_userq_evict()` is called from
  `amdgpu_eviction_fence_suspend_worker()` in `amdgpu_eviction_fence.c`
  (line 119). This is a workqueue callback triggered by
  `amdgpu_eviction_fence_enable_signaling()` (line 141), which is a
  dma_fence_ops callback. This means eviction happens automatically when
  BO resources need to be moved, making this a common code path during
  normal GPU operation.

**Step 5.3-5.4: Call chains**
- The eviction path is triggered when dma_fence signaling is enabled on
  eviction fences attached to BOs. This happens during VM page table
  operations, memory allocation, etc. - very common GPU operations.
- Record: The buggy path is reachable during normal GPU usage by any
  userspace GPU application.

---

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Does the buggy code exist in stable trees?**
- Verified `amdgpu_userq.c` does NOT exist in v6.12, v6.13, v6.14, or
  v6.15
- File first appears in v6.16
- The buggy `cancel_delayed_work_sync` in `amdgpu_userq_evict` exists in
  v6.16, v6.17, v6.18, v6.19, and v7.0
- This workspace is `linux-autosel-7.0`, evaluating for the 7.0.y stable
  tree
- Record: Bug exists in v7.0 (the target tree) and v6.19.y (current
  active stable).

**Step 6.2: Backport difficulty**
- The v7.0 version of the function is identical to the current HEAD -
  the patch should apply cleanly.
- Record: Clean apply expected.

---

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem**
- `drivers/gpu/drm/amd/amdgpu` - AMD GPU driver, one of the most widely
  used GPU drivers
- Criticality: IMPORTANT - affects all AMD GPU users
- Record: [drm/amdgpu] [IMPORTANT]

**Step 7.2: Activity**
- Very active subsystem with frequent commits
- Multiple deadlock fixes in the userqueue code recently, indicating
  this is a new subsystem under active development and bug fixing
- Record: Very active, new code with multiple recent fixes.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who is affected**
- All users of AMD GPUs with userqueue support (modern AMD hardware)
- Record: Driver-specific but large user population (all AMD GPU users
  with newer hardware)

**Step 8.2: Trigger conditions**
- The deadlock triggers when: (1) an eviction fence signals while (2)
  `fd_closing` is true and (3) a resume_work is pending or running
- This can happen during normal application shutdown/close while GPU
  operations are in progress
- Record: Triggered during fd close with concurrent GPU eviction -
  realistic scenario during application exit.

**Step 8.3: Failure mode severity**
- DEADLOCK = system hang (at minimum the GPU tasks hang, potentially
  wider if other kernel threads wait on the locked mutex)
- Severity: CRITICAL
- Record: [Deadlock -> system hang] [CRITICAL]

**Step 8.4: Risk-Benefit Ratio**
- BENEFIT: Very high - prevents deadlocks during normal GPU operation
- RISK: Very low - 2 lines added, 6 removed, obviously correct, written
  and reviewed by subsystem maintainers
- Record: [Very high benefit] [Very low risk] [Strongly favorable]

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Compilation**

FOR backporting:
- Fixes a real deadlock (CRITICAL severity)
- Very small, surgical fix (net -4 lines)
- Written by Christian König (senior AMD DRM maintainer)
- Reviewed by Alex Deucher (AMD's kernel graphics lead) and Sunil Khatri
- Bug exists in v7.0 (the target stable tree)
- Deadlock is triggered during normal operations (fd close with GPU
  activity)
- Obviously correct - removes the synchronous cancel that causes the
  deadlock
- Self-contained, no dependencies

AGAINST backporting:
- No items identified

Unresolved:
- Could not verify mailing list discussion (lore blocked)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** - The deadlock mechanism is
   clear and verifiable from code. Fix is minimal. Two Reviewed-by tags.
2. Fixes a real bug? **YES** - Deadlock during GPU eviction with
   fd_closing.
3. Important issue? **YES** - Deadlock = system hang (CRITICAL).
4. Small and contained? **YES** - Net -4 lines in a single function.
5. No new features or APIs? **YES** - Pure bug fix.
6. Can apply to stable trees? **YES** - Code in v7.0 is identical; clean
   apply expected.

**Step 9.3: Exception Categories**
- Not applicable - this is a standard bug fix, not an exception
  category.

**Step 9.4: Decision**
All evidence strongly supports backporting. This is a textbook deadlock
fix: small, surgical, obviously correct, fixes a critical issue, written
and reviewed by the subsystem maintainers.

---

## Verification

- [Phase 1] Parsed tags: Signed-off-by Christian König (author),
  Reviewed-by Alex Deucher, Reviewed-by Sunil Khatri, Signed-off-by Alex
  Deucher (committer)
- [Phase 2] Diff analysis: Removes `cancel_delayed_work_sync()` call in
  `amdgpu_userq_evict()` (which is called under `userq_mutex`), replaces
  6-line if/cancel/return/else/schedule block with 2-line if-not-
  closing/schedule
- [Phase 3] git blame: `cancel_delayed_work_sync` at line 1391 was
  introduced by commit `f10eb185ad0552` (2025-05-07), fd_closing branch
  by `44cfdf368fb72c` (2024-11-20)
- [Phase 3] git log: Found related deadlock fix `648a0dc0d78c3` in same
  file, confirming pattern of locking issues
- [Phase 3] Author check: Christian König is a senior AMD DRM maintainer
  with extensive commit history
- [Phase 4] b4 dig: Could not find the specific fix commit (likely too
  recent); found original buggy series at lore
- [Phase 4] UNVERIFIED: Could not access lore.kernel.org due to anti-
  scraping protection
- [Phase 5] Caller analysis: `amdgpu_userq_evict()` called from
  `amdgpu_eviction_fence_suspend_worker()` which holds `userq_mutex`
  (verified in amdgpu_eviction_fence.c lines 110-119)
- [Phase 5] Deadlock chain verified: suspend_worker(holds userq_mutex)
  -> cancel_delayed_work_sync(resume_work) -> resume_worker calls
  flush_delayed_work(suspend_work) at line 1277 AND
  mutex_lock(userq_mutex) at line 1279 = DEADLOCK
- [Phase 6] File existence check: `amdgpu_userq.c` does NOT exist in
  v6.12, v6.13, v6.14, v6.15; EXISTS in v6.16, v6.17, v6.18, v6.19, v7.0
- [Phase 6] Verified buggy `cancel_delayed_work_sync` in
  `amdgpu_userq_evict` exists in v6.16 through v7.0 (all versions
  checked)
- [Phase 6] Verified v7.0 code is identical to current HEAD - clean
  apply expected
- [Phase 8] Failure mode: Deadlock -> system hang during GPU fd close,
  severity CRITICAL

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
index 09f1d05328897..e8d12556d690a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
@@ -1389,13 +1389,8 @@ amdgpu_userq_evict(struct amdgpu_userq_mgr *uq_mgr,
 	/* Signal current eviction fence */
 	amdgpu_eviction_fence_signal(evf_mgr, ev_fence);
 
-	if (evf_mgr->fd_closing) {
-		cancel_delayed_work_sync(&uq_mgr->resume_work);
-		return;
-	}
-
-	/* Schedule a resume work */
-	schedule_delayed_work(&uq_mgr->resume_work, 0);
+	if (!evf_mgr->fd_closing)
+		schedule_delayed_work(&uq_mgr->resume_work, 0);
 }
 
 int amdgpu_userq_mgr_init(struct amdgpu_userq_mgr *userq_mgr, struct drm_file *file_priv,
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] drm/amdgpu: validate fence_count in wait_fences ioctl

[Sasha Levin]

From: "Jesse.Zhang" <Jesse.Zhang@amd.com>

[ Upstream commit 2cef848812a071991c20090cbe051a0a96c50a0c ]

Add an early parameter check in amdgpu_cs_wait_fences_ioctl() to reject
a zero fence_count with -EINVAL.

dma_fence_wait_any_timeout() requires count > 0. When userspace passes
fence_count == 0, the call propagates down to dma_fence core which does
not expect a zero-length array and triggers a WARN_ON.

Return -EINVAL immediately so the caller gets a clear error instead of
hitting an unexpected warning in the DMA fence subsystem.

No functional change for well-formed userspace callers.

v2:
- Reworked commit message to clarify the parameter validation rationale
- Removed verbose crash log from commit description
- Simplified inline code comment

Reviewed-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Jesse Zhang <jesse.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I now have comprehensive information to complete the full analysis. Let
me compile the findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `drm/amdgpu`
- Action verb: "validate" (adding missing input validation = bug fix)
- Summary: Validates `fence_count` parameter in `wait_fences` ioctl to
  reject zero.
Record: [drm/amdgpu] [validate] [Adding missing input validation for
fence_count in wait_fences ioctl]

**Step 1.2: Tags**
- Reviewed-by: Vitaly Prosyak <vitaly.prosyak@amd.com> (AMD developer)
- Reviewed-by: Christian König <christian.koenig@amd.com> (DMA-fence
  subsystem maintainer)
- Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> (author)
- Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (AMD DRM
  maintainer, committer)
- No Fixes: tag (expected for autosel review)
- No Cc: stable (expected)
Record: Strong review signal — Christian König is the DRM scheduler /
DMA-fence maintainer. Alex Deucher is the AMD GPU maintainer.

**Step 1.3: Commit Body**
Bug: Userspace passes `fence_count == 0` to `AMDGPU_WAIT_FENCES` ioctl.
This propagates to `dma_fence_wait_any_timeout()`, which has
`WARN_ON(!count)`. The WARN_ON fires in the DMA fence subsystem.
Symptom: Kernel WARN_ON triggered from userspace input. On
`panic_on_warn` systems, this causes a kernel crash.
Fix: Return `-EINVAL` early when `fence_count == 0`.
Record: [Bug: WARN_ON trigger from userspace-controlled input] [Symptom:
kernel warning/crash] [Author's root cause: dma_fence_wait_any_timeout
requires count > 0]

**Step 1.4: Hidden Bug Fix Detection**
"Validate" = adding missing parameter check. This IS a bug fix: it
prevents a WARN_ON (and potential crash) from userspace-controlled
input.
Record: [Yes, this is a bug fix — adds missing input validation to
prevent WARN_ON from ioctl with zero count]

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Single file modified: `drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c`
- +7 lines (4-line comment + 2 lines of code + 1 blank line)
- Function modified: `amdgpu_cs_wait_fences_ioctl()`
Record: [1 file, +7 lines, single function, surgical fix]

**Step 2.2: Code Flow Change**
BEFORE: `fence_count == 0` passes through to `memdup_array_user`
(returns ZERO_SIZE_PTR), then reaches `dma_fence_wait_any_timeout()`
which fires `WARN_ON(!count)`.
AFTER: `fence_count == 0` is caught at ioctl entry, returns `-EINVAL`
immediately.
Record: [Before: WARN_ON triggered. After: clean EINVAL return]

**Step 2.3: Bug Mechanism**
Category: Missing input validation / parameter check.
Mechanism: The ioctl fails to validate a user-controlled parameter
before passing it to a core kernel API that has a `WARN_ON`
precondition. Verified at line 894 of `dma-fence.c`:

```894:894:drivers/dma-buf/dma-fence.c
        if (WARN_ON(!fences || !count || timeout < 0))
```

Record: [Missing input validation] [User-controlled count==0 triggers
WARN_ON in dma_fence_wait_any_timeout]

**Step 2.4: Fix Quality**
- Obviously correct: a simple zero-check before further processing.
- Minimal/surgical: 7 lines total including comments.
- Regression risk: None. `fence_count == 0` is meaningless ("wait for
  zero fences"), and the ioctl already failed (with WARN) in this case.
  Returning `-EINVAL` is the correct behavior.
- No API change for well-formed callers (as stated in the commit
  message).
Record: [Fix is obviously correct, minimal, no regression risk]

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
`amdgpu_cs_wait_fences_ioctl` was introduced by commit `eef18a827a9ec5`
(Junwei Zhang, 2016-11-04, "drm/amdgpu: add the interface of waiting
multiple fences (v4)"). This is v4.10-era code, present in ALL active
stable trees.
Record: [Bug introduced in eef18a827a9ec5, v4.10 timeframe, present in
all stable trees]

**Step 3.2: Fixes Tag**
No Fixes: tag present. The implicit target is `eef18a827a9ec5` which
introduced the ioctl without the validation.
Record: [No Fixes: tag. Original code from 2016.]

**Step 3.3: File History**
Recent changes to `amdgpu_cs.c` include `dea75df7afe14`
(memdup_array_user conversion) and `69050f8d6d075` (kzalloc_objs
treewide change). These are cosmetic/API modernizations that don't
affect the bug or fix logic.
Record: [Recent changes are cosmetic. Fix is standalone.]

**Step 3.4: Author**
Jesse Zhang is a regular AMD GPU contributor with multiple fix commits
in the subsystem (SDMA fixes, out-of-bounds fixes, etc.).
Record: [Active AMD subsystem contributor]

**Step 3.5: Dependencies**
The fix adds a simple `if` check at the start of the function, before
any recently-changed code. It does NOT depend on patches 2/3 in the
series (which touch different files/functions entirely). The series
patches are independent input validation improvements.
Record: [Standalone fix, no dependencies on other patches]

---

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Original Submission**
Found at https://lists.freedesktop.org/archives/amd-
gfx/2026-March/140748.html. This is v2 of the patch with reworked commit
message. No NAKs found.
Record: [Patch submitted March 2026. v2 incorporated review feedback on
commit message clarity.]

**Step 4.2: Reviewers**
Reviewed by Vitaly Prosyak (AMD) and Christian König (DMA-fence/DRM
scheduler maintainer). Committed by Alex Deucher (AMD DRM maintainer).
Record: [Subsystem maintainer reviewed and approved]

**Step 4.3: Bug Report**
No separate bug report link. The bug was found by code inspection (the
WARN_ON contract in `dma_fence_wait_any_timeout` is explicit).
Record: [Found by code review, not user report]

**Step 4.4: Series Context**
3-patch series, all independent input validation improvements. Patch 2/3
changes WARN to DRM_ERROR in `amdgpu_sched_ioctl` (separate
file/function). Each is standalone.
Record: [Independent patches in the series. This one is self-contained.]

**Step 4.5: Stable Discussion**
No explicit stable nomination found in the thread.
Record: [No explicit stable discussion, which is expected for autosel
candidates.]

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions Modified**
Only `amdgpu_cs_wait_fences_ioctl()`.

**Step 5.2: Callers**
This is a DRM ioctl handler registered via
`DRM_IOCTL_DEF_DRV(AMDGPU_WAIT_FENCES, ...)` with
`DRM_AUTH|DRM_RENDER_ALLOW`. It is reachable by any process with access
to `/dev/dri/renderDNN` — no special privileges required beyond
DRM_AUTH.
Record: [Ioctl handler, reachable from unprivileged userspace via render
node]

**Step 5.3-5.4: Call Chain**
Userspace ioctl -> `drm_ioctl` -> `amdgpu_cs_wait_fences_ioctl` -> (if
!wait_all) `amdgpu_cs_wait_any_fence` -> `dma_fence_wait_any_timeout` ->
`WARN_ON(!count)`.
Record: [Direct ioctl path, user-controlled trigger, WARN_ON reached
with fence_count=0]

**Step 5.5: Similar Patterns**
The `amdgpu_cs_wait_all_fences` path with count==0 doesn't hit a WARN_ON
(the for loop simply doesn't execute), but returns success for a
meaningless request. The fix correctly catches both paths by validating
at the ioctl entry point.
Record: [Fix covers both wait_all and wait_any paths]

---

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable**
The `amdgpu_cs_wait_fences_ioctl` function has existed since
`eef18a827a9ec5` (v4.10, November 2016). It exists in ALL active stable
trees.
Record: [Bug exists in all stable trees (v5.4, v5.10, v5.15, v6.1, v6.6,
v6.12)]

**Step 6.2: Backport Complications**
The fix adds a check at the very start of the function body, before any
code that has been recently modified. In older stable trees, the
`memdup_array_user` line would be `memdup_user` with a manual size
calculation instead, but the added check comes BEFORE that line. Minor
context adjustment may be needed for the surrounding `memdup` call, but
the fix itself is trivially applicable.
Record: [Clean or near-clean apply expected. Minor context difference in
older trees.]

**Step 6.3: Related Fixes in Stable**
No prior fix for this zero-count issue was found.
Record: [No prior fix exists in stable.]

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem**
DRM/AMDGPU — a widely used GPU driver (AMD is one of two major discrete
GPU vendors on Linux). Criticality: IMPORTANT.
Record: [drm/amdgpu, IMPORTANT — widely used GPU driver]

**Step 7.2: Activity**
Actively developed (many recent commits). The file has had multiple
changes since v6.6.
Record: [Very active subsystem]

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
All users with AMD GPUs (a very large population). Any process with DRM
render node access.
Record: [All AMD GPU users, unprivileged trigger]

**Step 8.2: Trigger Conditions**
Any process that opens `/dev/dri/renderDNN` and issues the
`AMDGPU_WAIT_FENCES` ioctl with `fence_count == 0`. This is trivially
triggerable — no special timing, no race, no specific hardware needed. A
single malformed ioctl call from any render-node-capable process
triggers it.
Record: [Trivially triggerable from unprivileged userspace.
Deterministic, no race needed.]

**Step 8.3: Failure Mode**
- `WARN_ON` fires in `dma_fence_wait_any_timeout()`: produces stack
  trace in kernel log.
- On systems with `panic_on_warn=1` (common in syzbot testing, some
  hardened deployments): full kernel panic.
- Even without `panic_on_warn`, repeated triggering can flood kernel
  logs and potentially be used for denial of service.
- Severity: **MEDIUM-HIGH** (WARN from unprivileged userspace, potential
  crash with panic_on_warn)
Record: [WARN_ON from userspace, CRITICAL with panic_on_warn, MEDIUM
otherwise]

**Step 8.4: Risk-Benefit**
- BENEFIT: High — prevents kernel warning/crash from trivial
  unprivileged userspace input on all AMD GPU systems.
- RISK: Very low — 2 lines of actual code (a simple zero-check),
  obviously correct, no functional change for valid callers, reviewed by
  subsystem maintainer.
Record: [High benefit, very low risk]

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence**
FOR backporting:
- Fixes a WARN_ON triggerable from unprivileged userspace via ioctl
- Trivial to trigger (deterministic, single ioctl call)
- Crash on `panic_on_warn` systems
- Reviewed by DMA-fence subsystem maintainer (Christian König) and AMD
  maintainer
- 7 lines total, 2 lines of logic — minimal and obviously correct
- Bug exists since v4.10 (2016), affects all stable trees
- Standalone fix with no dependencies
- No functional change for well-formed callers

AGAINST backporting:
- Not a crash for default kernel configuration (WARN, not BUG)
- No user report (found by code inspection)
- Minor context may differ in older stable trees

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — trivial zero-check, reviewed
   by maintainer
2. Fixes a real bug? **YES** — WARN_ON from userspace input
3. Important issue? **YES** — userspace-triggerable warning, crash with
   panic_on_warn
4. Small and contained? **YES** — 7 lines in one function
5. No new features or APIs? **YES** — purely input validation
6. Can apply to stable? **YES** — should apply cleanly or near-cleanly

**Step 9.3: Exception Categories**
N/A — this is a straightforward bug fix, no exception needed.

**Step 9.4: Decision**
The fix is small, surgical, obviously correct, reviewed by the subsystem
maintainer, and prevents a WARN_ON (potential crash) triggerable from
unprivileged userspace. It has existed in all stable trees since 2016.
The risk is negligible and the benefit is clear.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Christian König (DMA-fence
  maintainer), Reviewed-by Vitaly Prosyak, Signed-off Alex Deucher (AMD
  DRM maintainer)
- [Phase 2] Diff analysis: +7 lines in `amdgpu_cs_wait_fences_ioctl()`,
  adds `if (!wait->in.fence_count) return -EINVAL` before allocation
- [Phase 2] Confirmed WARN_ON at dma-fence.c:894: `WARN_ON(!fences ||
  !count || timeout < 0)` — verified by reading the source
- [Phase 2] Confirmed `memdup_array_user(ptr, 0, size)` returns
  ZERO_SIZE_PTR (not error), so zero count passes through to
  `dma_fence_wait_any_timeout`
- [Phase 3] git blame: `amdgpu_cs_wait_fences_ioctl` introduced in
  eef18a827a9ec5 (2016-11-04), confirmed present in p-5.10, p-5.15 tags
- [Phase 3] git log: no prior fix for this zero-count issue in file
  history
- [Phase 4] Found original submission at lists.freedesktop.org amd-gfx
  March 2026. v2 with reworked commit message. No NAKs.
- [Phase 4] Series is 3 independent patches; patch 2/3 touches different
  file (amdgpu_sched.c). This patch is standalone.
- [Phase 5] Ioctl registered with DRM_AUTH|DRM_RENDER_ALLOW — confirmed
  reachable from unprivileged userspace
- [Phase 5] Traced call chain: ioctl -> wait_any_fence ->
  dma_fence_wait_any_timeout -> WARN_ON(!count)
- [Phase 6] Bug exists in all active stable trees (code from 2016)
- [Phase 6] Fix applies before any recently-changed code; near-clean
  apply expected
- [Phase 8] Severity: WARN_ON from unprivileged userspace, crash with
  panic_on_warn; benefit high, risk very low

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 24e4b4fc91564..142022295fe15 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1747,6 +1747,13 @@ int amdgpu_cs_wait_fences_ioctl(struct drm_device *dev, void *data,
 	struct drm_amdgpu_fence *fences;
 	int r;
 
+	/*
+	 * fence_count must be non-zero; dma_fence_wait_any_timeout()
+	 * does not accept an empty fence array.
+	 */
+	if (!wait->in.fence_count)
+		return -EINVAL;
+
 	/* Get the fences from userspace */
 	fences = memdup_array_user(u64_to_user_ptr(wait->in.fences),
 				   wait->in.fence_count,
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] drm/amdgpu: fix shift-out-of-bounds when updating umc active mask

[Sasha Levin]

From: Hawking Zhang <Hawking.Zhang@amd.com>

[ Upstream commit 1394a4926f4bcff0dc6ac6deea5beeb2844297f0 ]

UMC node_inst_num can exceed 32, causing
(1 << node_inst_num) to shift a 32-bit int
out of bounds

Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a comprehensive analysis. Let
me compile the findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `drm/amdgpu`
- Action verb: "fix"
- Summary: Fixes shift-out-of-bounds when computing UMC active mask
Record: [drm/amdgpu] [fix] [shift-out-of-bounds in UMC active mask
calculation]

**Step 1.2: Tags**
- Signed-off-by: Hawking Zhang (author), Alex Deucher (maintainer)
- Reviewed-by: Likun Gao
- No Fixes: tag, no Reported-by:, no Cc: stable (expected for a
  candidate commit)
Record: Patch reviewed by AMD colleague, signed off by amdgpu maintainer
Alex Deucher. No bug reporter or explicit stable nomination.

**Step 1.3: Commit Body**
The commit message is concise: `node_inst_num` can exceed 32, causing
`(1 << node_inst_num)` to shift a 32-bit int out of bounds. This is
undefined behavior in C.
Record: Bug = shift of a 32-bit `1` by >= 32 positions. Symptom =
undefined behavior, incorrect computation of `umc.active_mask`. Root
cause = using `int` literal `1` instead of `1ULL` for a shift that can
reach 32 or more.

**Step 1.4: Hidden Bug Fix Detection**
Not hidden at all - the subject says "fix" and the bug mechanism is
clearly stated.
Record: This is a straightforward bug fix for UB.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c`
- 2 lines changed: `uint32_t` -> `u64` (variable type) and `1` -> `1ULL`
  (shift operand)
- Function modified: `amdgpu_discovery_read_from_harvest_table()`
Record: Single-file, 2-line surgical fix. Scope is minimal.

**Step 2.2: Code Flow Change**

Hunk 1 (line 777 equivalent):
- Before: `uint32_t umc_harvest_config = 0;` (32-bit variable)
- After: `u64 umc_harvest_config = 0;` (64-bit variable)
- Purpose: Allow storing harvest config bits for node instances >= 32

Hunk 2 (line 833):
- Before: `((1 << adev->umc.node_inst_num) - 1)` — `1` is `int` (32
  bits); shifting by >= 32 is UB
- After: `((1ULL << adev->umc.node_inst_num) - 1ULL)` — `1ULL` is
  `unsigned long long` (64 bits); safe for node_inst_num up to 63

Record: The fix widens both the intermediate shift result and the
accumulation variable to 64 bits, eliminating the UB.

**Step 2.3: Bug Mechanism**
This is category (f) **type/correctness fix** — specifically, a shift-
out-of-bounds / undefined behavior fix. In C, shifting an `int` by >=
its bit width (32) is undefined behavior per the standard. The result is
unpredictable and could yield an incorrect `active_mask`, which is used
to track which UMC (memory controller) instances are active.
Record: [Type/UB bug] [32-bit shift by >= 32 causes UB; fix uses 64-bit
types]

**Step 2.4: Fix Quality**
- Obviously correct: widening types to match the range of possible
  values is textbook UB fix
- Minimal/surgical: 2 lines
- Regression risk: extremely low — only changes type widths;
  `active_mask` is already `unsigned long` (64 bits on 64-bit systems)
Record: Fix is obviously correct, minimal, with near-zero regression
risk.

---

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
From git blame, the buggy code at lines 777 and 833 was introduced by
commit `2b595659d5aec7` (Candice Li, Feb 2023) — "drm/amdgpu: Support
umc node harvest config on umc v8_10". This commit was first included in
v6.4.
Record: Bug introduced in v6.4, present in all stable trees since
(6.6.y, 6.12.y, etc.).

**Step 3.2: Original Buggy Commit**
Verified via `git merge-base --is-ancestor`: commit 2b595659d5aec7 is
NOT in v6.1 or v6.3, but IS in v6.4 and v6.6.
Record: Bug exists in stable trees 6.4+, 6.6+. NOT in 6.1.y.

**Step 3.3: File History**
Recent changes to the file are mostly kmalloc refactoring (tree-wide
changes) and an IP block addition. No conflicting fixes for this
specific issue.
Record: Standalone fix, no prerequisites needed.

**Step 3.4: Author**
Hawking Zhang is a prolific AMD GPU contributor with 10+ recent commits
to the amdgpu subsystem, working on IP blocks, initialization, and RAS
features. He is an AMD engineer and a core contributor to this
subsystem.
Record: Author is a core amdgpu developer at AMD.

**Step 3.5: Dependencies**
The diff context shows `amdgpu_discovery_get_table_info()` and `struct
table_info *info`, which are NOT present in the 7.0 tree (which uses
`struct binary_header *bhdr` and direct access). The actual fix lines
(`uint32_t` -> `u64` and `1` -> `1ULL`) are present in both versions.
Record: Minor context differences for backport, but the fix itself is
trivially adaptable.

---

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1-4.2:** b4 dig could not find the original buggy commit on
lore (AMD GPU patches often go through freedesktop.org/amd-gfx list
rather than lore). Web search found related shift-out-of-bounds fixes in
the amdgpu subsystem but not the exact commit being analyzed — it may be
very recent (2026).
Record: Could not find the exact patch thread. This is common for AMD
GPU patches which flow through the amd-gfx list.

**Step 4.3-4.5:** No bug reports or stable-specific discussions found
for this exact issue.
Record: No external bug reports found.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Key Functions**
Modified function: `amdgpu_discovery_read_from_harvest_table()`

**Step 5.2-5.3: Impact Surface**
`adev->umc.active_mask` is used by:
1. `LOOP_UMC_NODE_INST()` macro — iterates over active UMC nodes for RAS
   error counting
2. `amdgpu_umc_loop_all_aid()` — iterates over UMC instances for RAS
   queries
3. `amdgpu_psp.c` — passed to PSP firmware as `active_umc_mask`

An incorrect `active_mask` could cause:
- Missing or incorrect RAS error reporting
- Wrong UMC instances being queried for errors
- Incorrect firmware configuration
Record: active_mask affects RAS error handling and firmware
configuration.

**Step 5.4: Call Chain**
`amdgpu_discovery_read_from_harvest_table()` is called during GPU
initialization (probe path). This is a one-time setup function, but its
result persists for the lifetime of the driver.
Record: Called during init, result affects ongoing UMC/RAS operations.

---

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The buggy code was introduced in v6.4 (commit
2b595659d5aec7). It exists in stable trees 6.6.y and later.
Record: Bug exists in 6.6.y, 6.12.y, and 7.0.y.

**Step 6.2:** The patch context differs slightly between the diff and
the 7.0 tree (helper function refactoring). The actual fix lines apply
conceptually with minor context adjustment.
Record: May need minor context adaptation for clean apply.

---

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:** drm/amdgpu is an IMPORTANT subsystem (widely used GPU
driver on AMD hardware).
**Step 7.2:** Very actively developed.
Record: [IMPORTANT] [Very active subsystem]

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affects users of AMD GPUs with >= 32 UMC node instances
(large server/datacenter GPUs like MI300 series, where `node_inst_num`
can reach 32+).
Record: Driver-specific, primarily affects large AMD datacenter GPUs.

**Step 8.2:** Triggers during GPU initialization when the hardware has
>= 32 UMC instances. Deterministic, not a race condition.
Record: Deterministic trigger on specific hardware configurations.

**Step 8.3:** The undefined behavior from the shift can produce an
incorrect `active_mask`, leading to wrong RAS error reporting and
potentially incorrect firmware configuration. While not a crash, UB can
cause any result including crashes on some compilers/architectures.
Record: Severity = MEDIUM-HIGH (UB, incorrect hardware config, potential
RAS malfunction).

**Step 8.4:**
- BENEFIT: Fixes real UB on production hardware (large AMD GPUs),
  ensures correct memory controller tracking
- RISK: 2-line type widening change, extremely low risk of regression
Record: High benefit, very low risk.

---

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Fixes undefined behavior (shift-out-of-bounds) that is a clear
  violation of the C standard
- Affects real hardware (AMD GPUs with >= 32 UMC instances, e.g., MI300
  series)
- Minimal, 2-line fix that is obviously correct
- Reviewed by AMD engineer, signed off by amdgpu maintainer
- `active_mask` is used in RAS (reliability) error handling — getting
  this wrong affects hardware reliability monitoring
- Bug has existed since v6.4, present in all current stable trees except
  6.1.y
- Pattern matches other accepted stable fixes (shift-type fixes in
  amdgpu, e.g., `BIT()` -> `BIT_ULL()`)

**Evidence AGAINST backporting:**
- No Fixes: tag (expected)
- No explicit bug report or syzbot report
- Impact is limited to specific large GPU configurations
- Context differs slightly from stable trees (may need minor adaptation)

**Stable Rules Checklist:**
1. Obviously correct and tested? **YES** — type widening is trivially
   correct
2. Fixes a real bug? **YES** — undefined behavior per C standard
3. Important issue? **YES** — UB can cause incorrect hardware
   configuration
4. Small and contained? **YES** — 2 lines in 1 file
5. No new features/APIs? **YES** — pure fix
6. Can apply to stable? **YES** — with minor context adaptation

---

## Verification

- [Phase 1] Parsed subject: "drm/amdgpu: fix shift-out-of-bounds" —
  clear fix commit
- [Phase 2] Diff analysis: 2 lines changed — `uint32_t` -> `u64` and `1`
  -> `1ULL` in `amdgpu_discovery_read_from_harvest_table()`
- [Phase 3] git blame: buggy code introduced by commit 2b595659d5aec7
  (Candice Li, Feb 2023, v6.4)
- [Phase 3] git merge-base: confirmed commit 2b595659d5aec7 is in v6.4
  and v6.6, NOT in v6.1
- [Phase 3] git log --author: Hawking Zhang is a prolific AMD GPU
  contributor
- [Phase 4] b4 dig: could not find original submission on lore (AMD GPU
  patches go through freedesktop.org)
- [Phase 4] Web search: found related shift fixes in amdgpu but not
  exact patch thread
- [Phase 5] Grep: `active_mask` is `unsigned long` (64-bit), used by
  LOOP_UMC_NODE_INST macro, PSP firmware init, and RAS error queries
- [Phase 5] Grep: `node_inst_num` is `uint32_t`, incremented per
  UMC_HWID found; on gmc_v9_0, divided by 4 (can be 32+ on large GPUs)
- [Phase 6] Code exists in stable trees 6.6.y+; context differs slightly
  (bhdr vs table_info helper)
- [Phase 8] Failure mode: UB from shift, potentially incorrect
  active_mask affecting RAS operations
- UNVERIFIED: Exact patch discussion on amd-gfx mailing list (not found
  via search)
- UNVERIFIED: Whether UBSAN has actually fired on this in practice (no
  syzbot report)

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index af3d2fd61cf3f..32455b01bceb1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -774,7 +774,7 @@ static void amdgpu_discovery_read_from_harvest_table(struct amdgpu_device *adev,
 	struct harvest_table *harvest_info;
 	u16 offset;
 	int i;
-	uint32_t umc_harvest_config = 0;
+	u64 umc_harvest_config = 0;
 
 	bhdr = (struct binary_header *)discovery_bin;
 	offset = le16_to_cpu(bhdr->table_list[HARVEST_INFO].offset);
@@ -830,7 +830,7 @@ static void amdgpu_discovery_read_from_harvest_table(struct amdgpu_device *adev,
 		}
 	}
 
-	adev->umc.active_mask = ((1 << adev->umc.node_inst_num) - 1) &
+	adev->umc.active_mask = ((1ULL << adev->umc.node_inst_num) - 1ULL) &
 				~umc_harvest_config;
 }
 
-- 
2.53.0

[PATCH AUTOSEL 7.0] drm/amdgpu/userq: remove queue from doorbell xa during clean up

[Sasha Levin]

From: Sunil Khatri <sunil.khatri@amd.com>

[ Upstream commit a978ed3d6454e4aa1a2ac74051ffd77b7d263e44 ]

If function amdgpu_userq_map_helper fails we do need to clean
up and remove the queue from the userq_doorbell_xa.

Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed. Here's my complete analysis:

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
- **Subsystem**: `drm/amdgpu/userq` (AMD GPU userqueue subsystem)
- **Action verb**: "remove" (cleanup action - removing stale entry)
- **Summary**: Remove queue from doorbell XArray during error path
  cleanup when `amdgpu_userq_map_helper` fails.

Record: [drm/amdgpu/userq] [remove/clean up] [Fix missing doorbell
XArray cleanup on map_helper failure path]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by: Sunil Khatri** - Author of the fix
- **Reviewed-by: Christian König** - Prominent AMD GPU kernel developer
  and subsystem maintainer
- **Signed-off-by: Alex Deucher** - AMD GPU subsystem maintainer (commit
  path)
- No Fixes: tag, no Cc: stable, no Reported-by, no Link: tags

Record: Reviewed by Christian König (key AMD GPU developer). Signed off
by Alex Deucher (subsystem maintainer). No Fixes tag - expected for
manual review.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit message is brief but clear: "If function
amdgpu_userq_map_helper fails we do need to clean up and remove the
queue from the userq_doorbell_xa."

This explicitly states a missing cleanup on an error path. The failure
mode is a stale entry left in the doorbell XArray after the queue memory
has been freed.

Record: Bug = missing resource cleanup on error path. Symptom =
stale/dangling pointer in `userq_doorbell_xa` after kfree.

### Step 1.4: DETECT HIDDEN BUG FIXES
This IS a bug fix, not hidden at all. The commit explicitly adds missing
error path cleanup. Without this fix, a use-after-free occurs because
the kfree'd queue remains in the doorbell XArray.

Record: Yes - this is a genuine error path resource cleanup fix (UAF
prevention).

---

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
- **Files changed**: 1 (`drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c`)
- **Lines added**: 1 line
- **Functions modified**: `amdgpu_userq_create`
- **Scope**: Single-file, single-line surgical fix in an error path.

Record: +1 line in 1 file, modifying error handling in
`amdgpu_userq_create`. Minimal surgical fix.

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
In `amdgpu_userq_create`:
1. Line 863: `xa_store_irq(&adev->userq_doorbell_xa, index, queue, ...)`
   stores the queue in the doorbell XArray
2. Line 870-871: `xa_alloc(&uq_mgr->userq_xa, &qid, queue, ...)`
   allocates a queue ID
3. Line 891: `amdgpu_userq_map_helper(queue)` tries to map the queue

**Before fix**: When `amdgpu_userq_map_helper` fails (line 892-899), the
error path does: `xa_erase(userq_xa)`, `fence_driver_free`,
`mqd_destroy`, `kfree(queue)` — but does NOT erase from
`userq_doorbell_xa`.

**After fix**: Adds `xa_erase_irq(&adev->userq_doorbell_xa, index)`
before the other cleanup calls, properly removing the stale entry.

Record: The fix adds the missing doorbell XArray cleanup so that after
kfree(queue), no dangling pointer remains in userq_doorbell_xa.

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Category**: Memory safety / Use-after-free

The queue is stored in `userq_doorbell_xa` at line 863. When
`amdgpu_userq_map_helper` fails, the queue is kfree'd at line 897. But
the doorbell XArray still holds the pointer to freed memory. This
pointer is accessed in 6 different
`xa_for_each(&adev->userq_doorbell_xa, ...)` loops:
- `amdgpu_userq_suspend` (line 1445): accesses `queue->userq_mgr`
- `amdgpu_userq_resume` (line 1471): accesses `queue->userq_mgr`
- `amdgpu_userq_stop_sched_for_enforce_isolation` (line 1501): accesses
  `queue->userq_mgr`, `queue->queue_type`
- `amdgpu_userq_start_sched_for_enforce_isolation` (line 1535): same
- `amdgpu_userq_pre_reset` (line 1589): accesses `queue->userq_mgr`,
  `queue->state`
- `amdgpu_userq_post_reset` (line 1617): accesses `queue->state`

Record: UAF - freed queue memory accessed via stale doorbell XArray
entry during suspend/resume/reset/enforce-isolation operations.

### Step 2.4: ASSESS THE FIX QUALITY
- The fix is obviously correct: `xa_erase_irq` is the right API (matches
  the cleanup function at line 463)
- It's minimal: single line
- No regression risk: it only affects the error path
- The cleanup function `amdgpu_userq_cleanup` at line 463 does the same
  `xa_erase_irq` call

Record: Obviously correct, minimal, no regression risk. Uses same
pattern as the normal cleanup path.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
- Line 863 (xa_store_irq): introduced by `f18719ef4bb7b0` (Jesse Zhang,
  Oct 2025) - "Convert amdgpu userqueue management from IDR to XArray"
- Lines 891-899 (map_helper error path): originally from
  `94976e7e5ede65` (Alex Deucher, Apr 2025), with refactoring by
  `dc21e39fd20c77` (Lijo Lazar, Nov 2025)

The bug was introduced by the IDR-to-XArray conversion
(`f18719ef4bb7b0`). When replacing `idr_remove` with `xa_erase`, the
author forgot to add `xa_erase_irq` for the new `userq_doorbell_xa` in
the `amdgpu_userq_map_helper` error path.

Record: Bug introduced by f18719ef4bb7b0 (Oct 2025 XArray conversion).
Present in 7.0 tree.

### Step 3.2: FOLLOW THE FIXES: TAG
No Fixes: tag present. The logical Fixes: target would be
`f18719ef4bb7b0` which IS in this 7.0 tree.

Record: The buggy commit f18719ef4bb7b0 exists in the stable tree.

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Recent history shows heavy refactoring of this file, including the
refcount commit (`65b5c326ce4103`, Mar 2026), XArray conversion, and
multiple error handling fixes. The userqueue code is under active
development.

Record: Actively developed file. Standalone fix - no series dependency
in subject.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Sunil Khatri is a regular AMD GPU contributor with extensive commit
history (30+ commits in `drivers/gpu/drm/amd/`). He is familiar with the
codebase and has authored multiple cleanup/fix patches.

Record: Regular AMD GPU contributor with subsystem knowledge.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
**CRITICAL FINDING**: The diff context shows that in mainline, the
`xa_alloc` error path (line 872-879 in stable) already contains
`xa_erase_irq(&adev->userq_doorbell_xa, index)`. However, in the current
stable tree, this line is MISSING from the `xa_alloc` error path. This
means there is a prerequisite commit that fixed the `xa_alloc` error
path, and this commit only fixes the `amdgpu_userq_map_helper` error
path.

Record: Prerequisite exists - the xa_alloc error path fix must be
applied first for this patch to apply cleanly. The patch context won't
match the stable tree without it.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1-4.5: PATCH DISCUSSION
I was unable to find the exact lore discussion for this commit via b4
dig or web search. The commit is too new to have been indexed. However,
the review chain is clear: Reviewed-by Christian König, Signed-off-by
Alex Deucher — both are the primary AMD GPU kernel maintainers.

Record: Could not find lore URL. Reviewed by top AMD GPU maintainers.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.2: FUNCTION AND CALLER ANALYSIS
- `amdgpu_userq_create` is called from `amdgpu_userq_ioctl` (line 1024),
  which is a DRM IOCTL handler — **reachable from userspace**.
- The buggy path (map_helper failure) is exercised when GPU hardware
  mapping fails, which can happen during resource contention, hardware
  errors, or device issues.
- The stale entry is then accessed by suspend/resume/reset paths which
  iterate `userq_doorbell_xa`.

Record: Bug is reachable from userspace IOCTL. UAF is triggered during
subsequent suspend/resume/reset operations.

### Step 5.3-5.5: CALL CHAIN
Userspace → `amdgpu_userq_ioctl` → `amdgpu_userq_create` →
`amdgpu_userq_map_helper` fails → stale doorbell_xa entry → any
`xa_for_each(&adev->userq_doorbell_xa)` → UAF

Record: Clear call chain from userspace to bug trigger to UAF
exploitation.

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE?
Yes. The `userq_doorbell_xa` was introduced by `f18719ef4bb7b0` which is
in the 7.0 tree. The `amdgpu_userq_map_helper` error path at line
891-899 exists and is missing the cleanup.

Record: Buggy code exists in 7.0 stable tree.

### Step 6.2: BACKPORT COMPLICATIONS
The diff context doesn't match the stable tree exactly. The `xa_alloc`
error path in mainline already has `xa_erase_irq`, but the stable tree
doesn't. This means the patch needs either a prerequisite commit or
manual rework to apply cleanly.

Record: Won't apply cleanly — needs prerequisite fix for xa_alloc error
path or minor rework.

### Step 6.3: RELATED FIXES ALREADY IN STABLE
No related fix for this specific issue exists in the stable tree.

Record: No prior fix exists.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
- **Subsystem**: `drivers/gpu/drm/amd/amdgpu` — AMD GPU driver
- **Criticality**: IMPORTANT — widely used GPU driver on desktop/laptop
  systems
- Userqueue is a newer feature but actively used

Record: IMPORTANT subsystem - AMD GPU is widely deployed.

### Step 7.2: SUBSYSTEM ACTIVITY
Extremely active — 10+ changes per month to this specific file. The
userqueue code is under heavy development.

Record: Very active, rapidly evolving code.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: AFFECTED USERS
Users of AMD GPUs with userqueue support enabled. This includes modern
AMD Radeon hardware.

Record: Driver-specific but for widely-used AMD GPUs.

### Step 8.2: TRIGGER CONDITIONS
Triggered when `amdgpu_userq_map_helper` fails during queue creation
(e.g., hardware map failure, resource exhaustion). The UAF manifests
when subsequent suspend/resume/reset operations iterate the doorbell
XArray.

Record: Triggered by queue creation failure followed by system operation
(suspend/resume/reset). Not extremely rare.

### Step 8.3: FAILURE MODE SEVERITY
**Use-after-free** — the doorbell XArray holds a dangling pointer to
freed memory. When the 6 `xa_for_each` loops iterate, they dereference
`queue->userq_mgr`, `queue->state`, `queue->queue_type`. This can cause:
- Kernel oops/panic (most likely)
- Data corruption (if freed memory is reallocated)
- Potential security vulnerability (UAF with userspace-controlled
  trigger)

Record: UAF → CRITICAL (kernel crash, potential security issue).

### Step 8.4: RISK-BENEFIT RATIO
- **Benefit**: HIGH — prevents UAF in a userspace-reachable GPU code
  path
- **Risk**: VERY LOW — single line addition to error path, using
  established API pattern
- **Ratio**: Very favorable

Record: High benefit, very low risk.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Fixes a real UAF bug (stale pointer in doorbell XArray after kfree)
- Single-line fix — minimal scope
- Obviously correct — mirrors the cleanup function at line 463
- Reviewed by Christian König (AMD GPU subsystem expert)
- Signed off by Alex Deucher (AMD GPU maintainer)
- Bug is reachable from userspace IOCTL
- UAF can be triggered during common operations (suspend/resume/reset)
- Buggy code exists in stable tree (introduced by f18719ef4bb7b0)

**AGAINST backporting:**
- No Fixes: tag (expected for manual review candidates)
- Prerequisite commit needed for clean application (xa_alloc error path
  fix)
- Userqueue is a newer, rapidly evolving feature
- May need rework to apply to stable

### Step 9.2: STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES — single line, matches existing
   cleanup pattern, reviewed by maintainer
2. **Fixes a real bug?** YES — UAF in error path
3. **Important issue?** YES — UAF → potential crash or security issue
4. **Small and contained?** YES — 1 line in 1 file
5. **No new features or APIs?** Correct — pure bugfix
6. **Can apply to stable?** Needs prerequisite or minor rework

### Step 9.3: EXCEPTION CATEGORIES
Not an exception category — this is a standard bug fix.

### Step 9.4: DECISION
The fix addresses a genuine use-after-free vulnerability in the AMD GPU
userqueue error handling path. The bug is reachable from userspace via
DRM IOCTL, and the UAF can be triggered during suspend/resume/reset
operations. The fix is a single-line, obviously correct addition that
mirrors the existing cleanup function pattern. It was reviewed by the
subsystem's top maintainers.

The only concern is that the patch may need a prerequisite commit
(xa_alloc error path fix) to apply cleanly. However, this is a practical
application concern, not a question of whether the fix should be
backported.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Christian König, Signed-off-by Alex
  Deucher (both AMD GPU maintainers)
- [Phase 2] Diff analysis: 1 line added to amdgpu_userq_map_helper error
  path in amdgpu_userq_create(); adds missing xa_erase_irq for
  userq_doorbell_xa
- [Phase 3] git blame: Buggy code introduced by f18719ef4bb7b0 (Jesse
  Zhang, Oct 2025, XArray conversion), confirmed present in stable tree
- [Phase 3] git show f18719ef4bb7b0: Confirmed the XArray conversion
  failed to add xa_erase_irq in both xa_alloc and map_helper error paths
- [Phase 3] Checked xa_alloc error path (line 872-879): CONFIRMED
  missing xa_erase_irq in stable tree, indicating a prerequisite commit
  exists
- [Phase 4] b4 dig: Failed to find match (commit likely too recent); web
  search also unsuccessful
- [Phase 4] Web search: Found related refcount commit discussion on
  lists.freedesktop.org
- [Phase 5] Grep for amdgpu_userq_create callers: Called from
  amdgpu_userq_ioctl (DRM IOCTL handler), reachable from userspace
- [Phase 5] Grep for xa_for_each userq_doorbell_xa: Found 6 iteration
  sites (suspend/resume/reset/enforce-isolation) — all access freed
  queue members
- [Phase 5] Read amdgpu_userq_cleanup (line 450-469): CONFIRMED correct
  cleanup uses xa_erase_irq, validating the fix pattern
- [Phase 6] Buggy code (f18719ef4bb7b0) confirmed in stable tree via git
  log
- [Phase 6] Context mismatch identified: mainline xa_alloc error path
  has xa_erase_irq but stable doesn't — prerequisite needed
- [Phase 8] Failure mode: UAF → kernel oops/potential security
  vulnerability, severity CRITICAL
- UNVERIFIED: Could not find the exact mainline commit hash or lore
  discussion thread

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
index 819c4c26416c3..1849894d2837b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
@@ -892,6 +892,7 @@ amdgpu_userq_create(struct drm_file *filp, union drm_amdgpu_userq *args)
 		r = amdgpu_userq_map_helper(queue);
 		if (r) {
 			drm_file_err(uq_mgr->file, "Failed to map Queue\n");
+			xa_erase_irq(&adev->userq_doorbell_xa, index);
 			xa_erase(&uq_mgr->userq_xa, qid);
 			amdgpu_userq_fence_driver_free(queue);
 			uq_funcs->mqd_destroy(queue);
-- 
2.53.0

[PATCH AUTOSEL 7.0] drm/amdkfd: fix kernel crash on releasing NULL sysfs entry

[Sasha Levin]

From: Eric Huang <jinhuieric.huang@amd.com>

[ Upstream commit 4ea64d482fc2cc85009fce5abdf4780ece00c31c ]

there is an abnormal case that When a process re-opens kfd
with different mm_struct(execve() called by user), the
allocated p->kobj will be freed, but missed setting it to NULL,
that will cause sysfs/kernel crash with NULL pointers in p->kobj
on kfd_process_remove_sysfs() when releasing process, and the
similar error on kfd_procfs_del_queue() as well.

Signed-off-by: Eric Huang <jinhuieric.huang@amd.com>
Reviewed-by: Kent Russell <kent.russell@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a complete analysis. Let me
compile the full report.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: drm/amdkfd
- **Action verb**: "fix" - explicitly a bug fix
- **Summary**: Fixes a kernel crash when releasing a NULL (dangling)
  sysfs entry

### Step 1.2: Tags
- **Signed-off-by**: Eric Huang <jinhuieric.huang@amd.com> (author)
- **Reviewed-by**: Kent Russell <kent.russell@amd.com> (AMD KFD team
  member)
- **Signed-off-by**: Alex Deucher <alexander.deucher@amd.com> (AMD DRM
  maintainer)
- No Fixes: tag, no Cc: stable, no Reported-by, no Link - absence
  expected

### Step 1.3: Commit Body
The commit message describes: when a process re-opens KFD with a
different `mm_struct` (after `execve()`), the allocated `p->kobj` is
freed via `kobject_put()` but not set to NULL. Later,
`kfd_process_remove_sysfs()` checks `if (!p->kobj)` - but since the
pointer is dangling (not NULL), the check passes and causes a kernel
crash. The same issue affects `kfd_procfs_del_queue()`.

**Failure mode**: kernel crash (NULL pointer dereference / use-after-
free on stale kobj pointer)

### Step 1.4: Hidden Bug Fix?
No hiding here - the subject and body explicitly say "fix kernel crash."

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files**: 1 file changed: `drivers/gpu/drm/amd/amdkfd/kfd_process.c`
- **Lines**: +2, -1 (net 1 line added)
- **Functions modified**: `kfd_procfs_del_queue()`,
  `kfd_create_process_sysfs()`
- **Scope**: Single-file, surgical fix

### Step 2.2: Code Flow Changes

**Hunk 1** (`kfd_procfs_del_queue`):
- Before: only checks `if (!q)` then proceeds to `kobject_del(&q->kobj)`
  and `kobject_put(&q->kobj)`
- After: checks `if (!q || !q->process->kobj)` - if the process's kobj
  was freed, skip queue cleanup since parent sysfs is gone

**Hunk 2** (`kfd_create_process_sysfs`):
- Before: on `kobject_init_and_add()` failure, calls
  `kobject_put(process->kobj)` and returns, leaving `process->kobj` as a
  dangling pointer
- After: adds `process->kobj = NULL` after `kobject_put()`, preventing
  dangling pointer

### Step 2.3: Bug Mechanism
This is a **dangling pointer / use-after-free** bug. After
`kobject_put()` frees the kobj, the pointer is not NULLed, so
`kfd_process_remove_sysfs()` later passes the `!p->kobj` guard and
dereferences the freed pointer.

### Step 2.4: Fix Quality
- Obviously correct: setting pointer to NULL after free is a textbook
  fix
- Minimal: 2 lines changed
- No regression risk: the NULL check prevents use of an already-freed
  object
- No locking changes, no API changes

---

## PHASE 3: GIT HISTORY

### Step 3.1: Blame
- `kfd_procfs_del_queue()` was introduced by commit 6d220a7e7971ec
  (Amber Lin, 2020-01-30) - old function
- `kfd_create_process_sysfs()` was introduced by commit 4cd255b9694647
  (Zhu Lingshan, 2025-04-22) - the commit that extracted sysfs creation
  into a separate function
- The error path that's missing `= NULL` was introduced in
  4cd255b9694647

### Step 3.2: Fixes target
No explicit Fixes: tag. The bug was introduced by 4cd255b9694647
("amdkfd: Introduce kfd_create_process_sysfs as a separate function").
This commit first appeared in v7.0-rc1 - confirmed NOT in v6.19,
v6.16-rc1, v6.15-rc1, or v6.14.

### Step 3.3: File History
Many intermediate changes between the buggy commit and the fix (treewide
refactoring, unrelated amdkfd changes). No other fix for this specific
issue.

### Step 3.4: Author
Eric Huang is an AMD developer with multiple amdkfd commits (pasid
debugfs, smi events, TLB flush, etc.) - a regular contributor to the
subsystem.

### Step 3.5: Dependencies
The fix modifies `kfd_create_process_sysfs()` which only exists since
4cd255b9694647 (v7.0-rc1). The fix is self-contained and needs no other
patches.

---

## PHASE 4: MAILING LIST

### Step 4.1: Patch Discussion
b4 dig found the original submission at:
`https://patch.msgid.link/20260327180036.131096-1-
jinhuieric.huang@amd.com`

The mbox shows:
- v1 submission on 2026-03-27 by Eric Huang
- Kent Russell replied with `Reviewed-by` on the same day
- No NAKs, no concerns raised
- No stable nomination by reviewers, but this is expected for commits in
  the autosel pipeline

### Step 4.2: Reviewers
Patch was sent to `amd-gfx@lists.freedesktop.org`, reviewed by Kent
Russell (AMD KFD team), committed by Alex Deucher (AMD DRM maintainer).
Appropriate review chain.

### Step 4.3: Bug Report
No external bug report link. The author discovered this through internal
testing of the execve() code path.

### Step 4.4: Related Patches
Single standalone patch (v1 only, no series).

### Step 4.5: Stable Discussion
No prior stable discussion found.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Functions Modified
- `kfd_procfs_del_queue()` - called to delete a queue's sysfs entry
- `kfd_create_process_sysfs()` - creates sysfs entries for a KFD process

### Step 5.2: Callers
- `kfd_procfs_del_queue()` called from `kfd_process_queue_manager.c` in
  two places: during queue destruction and queue resource cleanup
- `kfd_create_process_sysfs()` called from `kfd_process.c` (initial
  process creation) and `kfd_chardev.c` (secondary process context
  creation via ioctl)

### Step 5.3-5.4: Call Chain
The bug path: user calls `execve()` → KFD detects mm change → re-opens
KFD → `kfd_create_process_sysfs()` fails → dangling `kobj` → process
cleanup → `kfd_process_remove_sysfs()` → crash via stale pointer

### Step 5.5: Similar Patterns
The existing `kfd_process_remove_sysfs()` already has a `if (!p->kobj)
return;` guard (line 1158), which is the correct pattern. The bug is
that the error path in `kfd_create_process_sysfs()` doesn't maintain the
invariant that freed kobj should be NULL.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable Trees
The buggy function `kfd_create_process_sysfs()` was introduced in commit
4cd255b9694647, which is in v7.0-rc1 and v7.0 only. It is NOT in v6.19,
v6.14, or any earlier stable tree. The fix is only relevant for the
**7.0.y** stable tree.

### Step 6.2: Backport Complications
The fix should apply cleanly to 7.0.y since the code context matches
directly.

### Step 6.3: Related Fixes Already in Stable
No related fixes found.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem
- **Subsystem**: drivers/gpu/drm/amd/amdkfd - AMD GPU Kernel Fusion
  Driver
- **Criticality**: IMPORTANT - AMD GPU users running KFD compute
  workloads (ROCm, OpenCL)

### Step 7.2: Activity
Very active subsystem with frequent changes.

---

## PHASE 8: IMPACT AND RISK

### Step 8.1: Who Is Affected
Users of AMD GPU KFD (ROCm compute users) who hit the error path in
`kfd_create_process_sysfs()` during process creation, specifically when
`execve()` causes a re-open with a different mm.

### Step 8.2: Trigger
When `kobject_init_and_add()` fails during KFD process sysfs creation
AND the process later gets cleaned up. This is an error path, but can be
triggered by resource exhaustion or sysfs conflicts.

### Step 8.3: Failure Mode
**CRITICAL**: Kernel crash (use of dangling pointer / NULL dereference
in sysfs teardown).

### Step 8.4: Risk-Benefit
- **Benefit**: HIGH - prevents kernel crash
- **Risk**: VERY LOW - 2-line fix, setting pointer to NULL after free
  and adding a NULL check
- **Ratio**: Strongly favorable

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence
**FOR backporting:**
- Fixes a kernel crash (dangling pointer causes crash in sysfs teardown)
- Tiny fix: 2 lines changed in 1 file
- Obviously correct (NULL pointer after free, NULL check before use)
- Reviewed by subsystem developer (Kent Russell)
- Committed by subsystem maintainer (Alex Deucher)
- Standalone fix with no dependencies
- Buggy code exists in 7.0.y stable tree

**AGAINST backporting:**
- Error path only (not every user will hit this)
- Only affects 7.0.y (the buggy code is new in v7.0-rc1)
- No Fixes: tag (expected for autosel candidates)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** - trivial NULL-after-free
   pattern, reviewed
2. Fixes a real bug? **YES** - kernel crash on sysfs teardown
3. Important issue? **YES** - kernel crash (CRITICAL severity)
4. Small and contained? **YES** - 2 lines, 1 file
5. No new features or APIs? **YES** - pure bug fix
6. Can apply to stable? **YES** - code exists in 7.0.y, should apply
   cleanly

### Step 9.3: Exception Categories
Not an exception category - this is a standard bug fix.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Kent Russell, Signed-off-by Alex
  Deucher (maintainer), no Fixes/Cc-stable
- [Phase 2] Diff analysis: +2/-1 lines; adds `process->kobj = NULL`
  after `kobject_put()` and `!q->process->kobj` check in
  `kfd_procfs_del_queue()`
- [Phase 3] git blame: error path introduced by 4cd255b9694647 (Zhu
  Lingshan, 2025-04-22)
- [Phase 3] git merge-base: 4cd255b9694647 is in v7.0-rc1 and v7.0, NOT
  in v6.19 or earlier
- [Phase 3] git log between buggy and fix: no intermediate fix for same
  issue found
- [Phase 4] b4 dig: found original at `https://patch.msgid.link/20260327
  180036.131096-1-jinhuieric.huang@amd.com`
- [Phase 4] b4 dig -a: single v1 submission, no revisions
- [Phase 4] mbox review: Kent Russell gave Reviewed-by, no NAKs or
  concerns
- [Phase 5] Grep callers: `kfd_procfs_del_queue()` called from
  `kfd_process_queue_manager.c` (2 sites); `kfd_create_process_sysfs()`
  called from both `kfd_process.c` and `kfd_chardev.c`
- [Phase 5] `kfd_process_remove_sysfs()` at line 1158 already has `if
  (!p->kobj) return;` guard, confirming the invariant the fix maintains
- [Phase 6] Buggy code only in v7.0-rc1+, fix relevant for 7.0.y stable
  only
- [Phase 8] Failure mode: kernel crash on dangling pointer dereference
  during sysfs teardown, severity CRITICAL

The fix is small, surgical, obviously correct, and prevents a kernel
crash. It meets all stable kernel criteria.

**YES**

 drivers/gpu/drm/amd/amdkfd/kfd_process.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 12e24fbf8c463..c6782904d2f1c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -679,7 +679,7 @@ static void kfd_procfs_add_sysfs_files(struct kfd_process *p)
 
 void kfd_procfs_del_queue(struct queue *q)
 {
-	if (!q)
+	if (!q || !q->process->kobj)
 		return;
 
 	kobject_del(&q->kobj);
@@ -858,6 +858,7 @@ int kfd_create_process_sysfs(struct kfd_process *process)
 	if (ret) {
 		pr_warn("Creating procfs pid directory failed");
 		kobject_put(process->kobj);
+		process->kobj = NULL;
 		return ret;
 	}
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] drm/amdgpu: clear related counter after RAS eeprom reset

[Sasha Levin]

From: Tao Zhou <tao.zhou1@amd.com>

[ Upstream commit 3d77ca68eb0b48f88cc891d1b98f109b68e2ffcf ]

Make eeprom data and its counter consistent.

Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: `drm/amdgpu` (AMD GPU driver, RAS subsystem)
- **Action verb**: "clear" (indicating missing cleanup / consistency
  fix)
- **Summary**: Clear the `count_saved` counter when RAS EEPROM table is
  reset

Record: [drm/amdgpu] [clear] [Ensure count_saved is zeroed when EEPROM
table is reset]

### Step 1.2: Tags
- **Signed-off-by**: Tao Zhou (author, regular AMD RAS contributor)
- **Reviewed-by**: Hawking Zhang (AMD subsystem lead for RAS)
- **Signed-off-by**: Alex Deucher (AMD GPU maintainer, final commit)
- No Fixes: tag, no Reported-by:, no Cc: stable

Record: Author is a regular AMD RAS contributor. Reviewed by AMD's RAS
lead.

### Step 1.3: Commit Body
- "Make eeprom data and its counter consistent"
- Terse description, but the intent is clear: a data consistency issue
  between EEPROM state and in-memory counters.

Record: Bug is a data consistency issue. After EEPROM reset,
`count_saved` retains a stale value while all other counters are zeroed.

### Step 1.4: Hidden Bug Fix Detection
This is a data consistency bug disguised as a minor cleanup. The word
"consistent" signals that the code was **inconsistent** before—i.e., the
counter was wrong after a reset. This is a real bug fix.

Record: Yes, this is a hidden bug fix. The "consistent" language masks
the fact that stale `count_saved` causes wrong data to be written to
EEPROM on subsequent saves.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files**: 1 file modified (`amdgpu_ras_eeprom.c`)
- **Lines**: +3 (one comment, one NULL check, one assignment)
- **Function modified**: `amdgpu_ras_eeprom_reset_table()`
- **Scope**: Single-file surgical fix

### Step 2.2: Code Flow Change
- **Before**: `amdgpu_ras_eeprom_reset_table()` zeroed `ras_num_recs`,
  `ras_num_bad_pages`, `ras_num_mca_recs`, `ras_num_pa_recs`, `ras_fri`,
  `bad_channel_bitmap`, and `update_channel_flag`, but left
  `eh_data->count_saved` unchanged.
- **After**: Also zeroes `con->eh_data->count_saved` (with NULL guard on
  `eh_data`).

### Step 2.3: Bug Mechanism
This is a **data consistency / correctness bug**. `count_saved` is used
as an array index in `amdgpu_ras_save_bad_pages()`:

```3341:3341:drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
                                        &data->bps[data->count_saved],
unit_num)) {
```

If EEPROM is reset but `count_saved` retains value N from before, the
next save operation starts writing from `bps[N]` instead of `bps[0]`.
This means:
1. **Wrong data is written to EEPROM** (skipping the first N entries)
2. **Potential out-of-bounds access** if bps array was reorganized

There are direct call sequences that trigger this: `reset_table` ->
`save_bad_pages` at lines 1783-1784 and 3837-3838.

### Step 2.4: Fix Quality
- Obviously correct: when all EEPROM records are cleared, the "saved
  count" must be 0
- Minimal: 3 lines, single variable assignment with NULL guard
- No regression risk: the NULL check prevents any potential NULL deref

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
The reset function's body was built incrementally since v5.3 (2019) by
Andrey Grodzovsky, with additions by Luben Tuikov (2021), Stanley Yang
(2022), and Tao Zhou (2024). The `count_saved` field was introduced in
commit d45c5e6845a76 by Tao Zhou (2025-07-04), first appearing in v6.18.

### Step 3.2: No Fixes: tag
No Fixes: tag present. The logical "fixes" target would be d45c5e6845a76
which introduced `count_saved` without clearing it in the reset path.

### Step 3.3: File History
The file is actively developed with 20+ recent commits. Patch 1/2 of
this series ("compatible with specific RAS old eeprom format") modifies
`amdgpu_ras.c` and is thematically related but functionally independent.

### Step 3.4: Author
Tao Zhou is a frequent AMD RAS contributor (10+ recent commits to RAS
code) and the same author who introduced `count_saved`.

### Step 3.5: Dependencies
- **Requires** d45c5e6845a76 (introduces `count_saved` field) - present
  only in v6.18+
- **Does NOT depend on** patch 1/2 of the series (separate bug fix)
- Standalone fix

---

## PHASE 4: MAILING LIST RESEARCH

- Found at `lists.freedesktop.org/archives/amd-
  gfx/2026-February/139281.html`
- Part of a 2-patch series; b4 dig did not find a match (AMD internal
  submission path)
- Reviewed-by from Hawking Zhang (AMD RAS lead) for the entire series
- No NAKs or concerns raised
- No explicit stable nomination by reviewers

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.4: Function/Caller Analysis
`amdgpu_ras_eeprom_reset_table()` is called from:
1. **`amdgpu_ras_debugfs_eeprom_write()`** - user-triggered via debugfs
   (privileged only)
2. **`amdgpu_ras_eeprom_init()`** - during driver initialization (new
   table creation)
3. **`amdgpu_ras_eeprom_check_and_recover()`** - reset + immediate
   save_bad_pages
4. **`amdgpu_ras_init_badpage_info()`** - reset + immediate
   save_bad_pages (format upgrade path)

Call sites 3 and 4 are the dangerous ones: they call `reset_table`
immediately followed by `save_bad_pages`, which will use the stale
`count_saved` as an array index.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Which stable trees have the buggy code?
`count_saved` was introduced in d45c5e6845a76, first in v6.18. This fix
is only relevant for **v6.18.y and newer** stable trees.

### Step 6.2: Backport Difficulty
The patch is 3 lines, no surrounding context changes. Clean apply
expected on any tree containing d45c5e6845a76.

---

## PHASE 7: SUBSYSTEM CONTEXT

- **Subsystem**: drm/amdgpu RAS (Reliability, Availability,
  Serviceability)
- **Criticality**: IMPORTANT - RAS tracks and retires bad GPU memory
  pages. Incorrect tracking means potentially using defective memory, or
  incorrectly retiring good memory.
- Active subsystem with frequent development.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
Users with AMD GPUs that support RAS (datacenter GPUs like MI200, MI300
series). This is a significant enterprise/HPC user population.

### Step 8.2: Trigger Conditions
- Triggered when EEPROM table is reset and new bad pages are
  subsequently saved
- Can occur during: checksum recovery (automatic), table format upgrade
  (automatic), debugfs user action

### Step 8.3: Failure Mode
- **Data corruption**: Wrong records written to EEPROM (persists across
  reboots)
- **Potential OOB access**: If `count_saved` points beyond current `bps`
  array bounds
- Severity: **MEDIUM-HIGH** - corrupted RAS data means bad memory pages
  might not be properly tracked

### Step 8.4: Risk-Benefit
- **Benefit**: Prevents EEPROM data corruption and potential OOB access.
  Medium-high benefit for datacenter GPU users.
- **Risk**: Very low. 3 lines, single variable zeroed with NULL guard.
  Impossible to introduce a regression.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence

**FOR backporting:**
- Fixes a real data consistency bug: stale `count_saved` causes wrong
  data written to EEPROM
- Potential OOB array access from stale index
- 3-line fix, surgical, obviously correct
- Reviewed by AMD RAS subsystem lead (Hawking Zhang)
- Author is the same person who introduced `count_saved` (understands
  the code)
- Direct trigger paths exist (reset_table -> save_bad_pages sequences)
- Affects enterprise/datacenter GPU users (RAS is critical for data
  integrity)

**AGAINST backporting:**
- Only applicable to v6.18+ trees (where `count_saved` exists)
- No user-reported crash or bug report - preventive fix by the developer
- Limited user population (AMD datacenter GPUs with RAS)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** - zeroing a counter when table
   is reset is trivially correct
2. Fixes a real bug? **YES** - stale index causes wrong EEPROM writes
   and potential OOB access
3. Important issue? **YES** - data corruption of persistent RAS bad page
   table
4. Small and contained? **YES** - 3 lines in 1 file
5. No new features? **YES** - pure fix
6. Can apply to stable? **YES** - clean apply on v6.18+

### Step 9.3: Exception Categories
Not applicable (standard bug fix, not a quirk/ID/DT addition).

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Hawking Zhang, Signed-off-by Alex
  Deucher, Tao Zhou as author
- [Phase 2] Diff analysis: 3 lines added in
  `amdgpu_ras_eeprom_reset_table()`, clearing `count_saved` with NULL
  guard
- [Phase 2] Traced `count_saved` usage: used as array index in
  `amdgpu_ras_save_bad_pages()` at lines 3341, 3348
- [Phase 3] git blame: surrounding code added by various AMD developers
  2019-2024; `count_saved` introduced in d45c5e6845a76 (v6.18)
- [Phase 3] git merge-base --is-ancestor: confirmed d45c5e6845a76 NOT in
  v6.17, IS in v6.18
- [Phase 3] Author check: Tao Zhou has 10+ recent RAS commits,
  introduced `count_saved` himself
- [Phase 4] Found patch discussion at lists.freedesktop.org, Hawking
  Zhang reviewed both patches
- [Phase 4] Series is 2/2, patch 1/2 is independent (different file,
  different bug)
- [Phase 5] Traced callers of `amdgpu_ras_eeprom_reset_table`: found 4
  call sites, 2 immediately follow with `save_bad_pages` (lines
  1783-1784, 3837-3838) - confirming the bug is triggerable
- [Phase 6] Fix only applies to v6.18+ stable trees
- [Phase 8] Failure mode: wrong records written to EEPROM (data
  corruption), potential OOB array access

The fix is small, surgical, obviously correct, and addresses a real data
consistency bug that can cause EEPROM corruption and potential out-of-
bounds access. It meets all stable kernel criteria for applicable trees
(v6.18+).

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c
index 6fba9d5b29ea6..44fba4b6aa92a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c
@@ -508,6 +508,9 @@ int amdgpu_ras_eeprom_reset_table(struct amdgpu_ras_eeprom_control *control)
 	control->bad_channel_bitmap = 0;
 	amdgpu_dpm_send_hbm_bad_channel_flag(adev, control->bad_channel_bitmap);
 	con->update_channel_flag = false;
+	/* there is no record on eeprom now, clear the counter */
+	if (con->eh_data)
+		con->eh_data->count_saved = 0;
 
 	amdgpu_ras_debugfs_set_ret_size(control);
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.19] drm/amd/display: Restore full update for tiling change to linear

[Sasha Levin]

From: Joshua Aberback <joshua.aberback@amd.com>

[ Upstream commit 3967ab83a5075c05be3c614f1dc8460f66ee77ad ]

[Why]
There was previously a dc debug flag to indicate that tiling
changes should only be a medium update instead of full. The
function get_plane_info_type was refactored to not rely on dc
state, but in the process the logic was unintentionally changed,
which leads to screen corruption in some cases.

[How]
 - add flag to tiling struct to avoid full update when necessary

Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Aric Cyr <aric.cyr@amd.com>
Signed-off-by: Joshua Aberback <joshua.aberback@amd.com>
Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I now have a comprehensive understanding of this commit. Let me compile
the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `drm/amd/display`
- Action verb: "Restore" (indicating a regression fix — restoring
  previous correct behavior)
- Summary: Restoring full update for tiling change to linear to fix
  screen corruption
- Record: [drm/amd/display] [Restore] [Fix screen corruption by
  restoring full update for tiling changes to linear]

**Step 1.2: Tags**
- Reviewed-by: Nicholas Kazlauskas (AMD display core team) and Aric Cyr
  (AMD display team lead)
- Signed-off-by: Joshua Aberback (author), Chuanyu Tseng, Alex Deucher
  (AMD GPU maintainer)
- No Fixes: tag (expected for autosel candidates)
- No Reported-by: tag
- Record: Two reviews from AMD display engineers, signed off by GPU
  maintainer

**Step 1.3: Commit Body**
- Bug: Refactoring of `get_plane_info_type` unintentionally changed
  logic, leading to **screen corruption** in some cases
- Root cause: When tiling changes were refactored to not rely on dc
  state, the default behavior was changed from "always full update" to
  "conditional full update (only for non-linear)"
- Fix: Add a flag to the tiling struct to explicitly control when to
  avoid full update
- Record: Screen corruption caused by accidental logic change during
  refactoring. Failure mode is visual corruption.

**Step 1.4: Hidden Bug Fix Detection**
- This is explicitly described as fixing screen corruption. Not hidden
  at all — it's a clear regression fix.
- Record: Explicit bug fix for visual corruption regression.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- `dc/core/dc.c`: ~20 lines removed (switch/case), ~6 lines added (flag-
  based logic). Net -16 lines.
- `dc/dc_hw_types.h`: 4 lines added (new `flags` sub-struct in
  `dc_tiling_info`)
- Functions modified: `get_plane_info_update_type()` in dc.c
- Record: 2 files, ~24 lines changed, single-function surgical fix plus
  struct addition

**Step 2.2: Code Flow Change**
- Before: Switch on `tiling->gfxversion`, only FULL update when swizzle
  is non-linear. Linear tiling changes get MED only.
- After: Check `tiling->flags.avoid_full_update_on_tiling_change`. If
  false (default), always FULL update. If true, MED update.
- Effect: Default is now always FULL update on tiling change (safe,
  conservative behavior), matching the pre-refactoring default.

**Step 2.3: Bug Mechanism**
- Category: Logic/correctness fix (restoring accidentally changed
  behavior)
- Original code (pre-03a593b1acbaf5): Always FULL unless
  `dc->debug.skip_full_updated_if_possible`
- Buggy code (03a593b1acbaf5): Only FULL for non-linear swizzle changes
- Fix: Restore always-FULL as default

**Step 2.4: Fix Quality**
- Obviously correct: yes, the default-to-FULL is the safe/conservative
  path
- Minimal/surgical: yes, tightly scoped to one function + one struct
- Regression risk: Potential for more FULL updates than necessary
  (performance cost, not correctness)
- Record: High quality fix, reviewed by two display engineers

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
- Buggy switch/case logic introduced by `03a593b1acbaf5` (Dominik
  Kaszewski, 2025-07-15) "Remove dc state from check_update"
- This commit is present in 7.0 (confirmed via `git merge-base --is-
  ancestor`)
- First appeared in v6.19

**Step 3.2: Fixes Tag**
- No Fixes: tag present (expected for autosel candidate)
- Manually identified: `03a593b1acbaf5` is the commit that introduced
  the regression

**Step 3.3: File History**
- Related: `d637dd7288814` reverted `08a01ec306dbd` (another tiling fix
  that caused blank screens)
- Related: `bf95cf7f7a068` "Fix performance regression from full
  updates" by same refactoring author
- The display tiling update logic has been an active area of changes and
  fixes

**Step 3.4: Author**
- Joshua Aberback is a regular AMD display contributor (15+ commits to
  display subsystem)
- Previously authored `ce5057885ff70` "Clip rect size changes should be
  full updates" — a very similar type of fix
- Also reviewed the revert `d637dd7288814`

**Step 3.5: Dependencies**
- The commit requires `03a593b1acbaf5` to be present (it is — verified
  as ancestor of HEAD)
- The commit requires `45de10d2d9366` for the `LOCK_DESCRIPTOR_*` enum
  values (also present)
- No other dependencies found. The commit is standalone.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1-4.5:**
- b4 dig could not find the patch on lore.kernel.org (AMD display
  patches often go through internal drm-misc/amd trees)
- lore.kernel.org blocked by Anubis anti-scraping
- Given the AMD display team's internal review process (two Reviewed-by
  tags from senior engineers + GPU maintainer sign-off), the patch went
  through proper review

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions Modified**
- `get_plane_info_update_type()` — the only function modified in the
  logic

**Step 5.2: Callers**
- Called from `det_surface_update()` →
  `check_update_surfaces_for_stream()` →
  `dc_check_update_surfaces_for_stream()`
- This is the core display update path — called for every plane update
  on AMD GPUs

**Step 5.3-5.4: Call Chain**
- Reachable from: DRM atomic commit → amdgpu_dm →
  dc_check_update_surfaces_for_stream
- This is a HOT PATH — triggered on every display update for AMD GPU
  users

**Step 5.5: Similar Patterns**
- The `bundle` structs containing `dc_plane_info` are allocated with
  `kzalloc`, ensuring the new `flags` field is zero-initialized on the
  update path

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable**
- Introduced in `03a593b1acbaf5` (v6.19)
- Present in 7.0 tree (verified)
- NOT present in 6.6.y or earlier stable trees (pre-dates the
  regression)

**Step 6.2: Backport Complications**
- The diff context lines match the current 7.0 code exactly — clean
  apply expected
- The `elevate_update_type` 3-argument signature matches (introduced by
  `45de10d2d9366`)
- The `dc_tiling_info` struct matches (revert `d637dd7288814` already
  applied)

**Step 6.3: Related Fixes in Stable**
- No related fix for this specific issue found in stable

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:**
- Subsystem: GPU/Display (drm/amd/display)
- Criticality: IMPORTANT — affects all AMD GPU users
- Record: AMD GPU display driver, widely used on desktops and laptops

**Step 7.2:**
- Very active subsystem with frequent changes
- The tiling update logic area has seen multiple fixes recently

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
- All AMD GPU users (Radeon RX, integrated APUs) using this kernel
  version
- Particularly affects GFX9+ hardware where tiling transitions occur

**Step 8.2: Trigger Conditions**
- Tiling mode changes to linear (e.g., during mode switches, overlay
  plane changes)
- Can be triggered during normal desktop usage

**Step 8.3: Failure Mode**
- **Screen corruption** — CRITICAL visual artifact
- Severity: HIGH (screen corruption is visible and disruptive, though
  not data-corrupting)

**Step 8.4: Risk-Benefit**
- BENEFIT: Fixes screen corruption for AMD GPU users — HIGH
- RISK: ~24 lines changed, adds a struct field (low risk), default is
  conservative FULL update path. May cause minor performance overhead
  from extra FULL updates — LOW
- Ratio: HIGH benefit / LOW risk = FAVORABLE

## PHASE 9: SYNTHESIS

**Step 9.1: Evidence**
FOR backporting:
- Fixes screen corruption (serious visual bug)
- Root cause clearly identified: logic change during refactoring
  (03a593b1acbaf5)
- Small, surgical fix (~24 lines across 2 files)
- Reviewed by two AMD display engineers (Kazlauskas, Cyr)
- Signed off by AMD GPU maintainer (Deucher)
- Standalone fix (no dependencies beyond what's in tree)
- Would apply cleanly to 7.0
- Default behavior is conservative (always FULL update)
- Author has track record of similar valid fixes (ce5057885ff70)

AGAINST backporting:
- Adds a new struct field (flags.avoid_full_update_on_tiling_change) —
  minor struct extension
- The flag is never set to true in this tree, making it effectively dead
  code
- A simpler fix (just always elevate to FULL without adding the flag)
  could have been used
- Potential (minor) performance regression from more FULL updates

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? YES — two reviews, conservative default
2. Fixes a real bug? YES — screen corruption
3. Important issue? YES — screen corruption on AMD GPUs
4. Small and contained? YES — ~24 lines, 2 files, 1 function
5. No new features or APIs? The flag is new but internal-only and serves
   the fix
6. Can apply to stable? YES — context matches exactly

**Step 9.3: Exception Categories**
- Not an exception category; this is a standard bug fix

**Step 9.4: Decision**
This is a clear regression fix for screen corruption caused by
accidental logic change during refactoring. The fix is small, well-
reviewed, standalone, and defaults to the safe conservative behavior.
The struct field addition is internal-only and zero-initialized.

## Verification

- [Phase 1] Parsed tags: Reviewed-by: Nicholas Kazlauskas, Reviewed-by:
  Aric Cyr, three SOBs including Alex Deucher
- [Phase 2] Diff analysis: switch/case (20 lines) replaced with flag-
  check (6 lines) in `get_plane_info_update_type()`, plus 4-line struct
  addition
- [Phase 3] git blame: Buggy code introduced by `03a593b1acbaf5`
  (2025-07-15, v6.19), confirmed in 7.0 tree via `git merge-base --is-
  ancestor`
- [Phase 3] git show 03a593b1acbaf5: Confirmed refactoring replaced
  `dc->debug.skip_full_updated_if_possible` check with per-gfxversion
  switch, changing default from FULL to conditional
- [Phase 3] Related commits: `d637dd7288814` (revert of another tiling
  fix), `bf95cf7f7a068` (performance regression fix in same area)
- [Phase 3] Author check: Joshua Aberback has 15+ commits to AMD
  display, authored similar fix `ce5057885ff70`
- [Phase 4] b4 dig: Could not find original submission (AMD patches
  often go through internal trees)
- [Phase 4] lore.kernel.org: Blocked by Anubis protection
- [Phase 5] Callers traced: `get_plane_info_update_type()` →
  `det_surface_update()` → `dc_check_update_surfaces_for_stream()` — hot
  path for all AMD display updates
- [Phase 5] Bundle allocations at lines 3364 and 9949 both use kzalloc,
  ensuring flags field is zero-initialized
- [Phase 6] `git tag --contains 03a593b1acbaf5`: buggy code in v6.19 and
  7.0 only
- [Phase 6] Current tree code at lines 2748-2775 matches diff "before"
  context exactly — clean apply
- [Phase 6] `elevate_update_type` signature (3 args) matches at line 151
- [Phase 8] Failure mode: screen corruption on tiling change to linear,
  severity HIGH
- UNVERIFIED: Exact user reproduction scenario (commit message says
  "some cases" without specifics)
- UNVERIFIED: Whether any downstream code eventually sets the flag to
  true (but irrelevant — default false is the safe path)

**YES**

 drivers/gpu/drm/amd/display/dc/core/dc.c     | 26 ++++----------------
 drivers/gpu/drm/amd/display/dc/dc_hw_types.h |  4 +++
 2 files changed, 9 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 47064e9bc08ad..7107529e90295 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2749,28 +2749,12 @@ static struct surface_update_descriptor get_plane_info_update_type(const struct
 
 	if (memcmp(tiling, &u->surface->tiling_info, sizeof(*tiling)) != 0) {
 		update_flags->bits.swizzle_change = 1;
-		elevate_update_type(&update_type, UPDATE_TYPE_MED, LOCK_DESCRIPTOR_STREAM);
 
-		switch (tiling->gfxversion) {
-		case DcGfxVersion9:
-		case DcGfxVersion10:
-		case DcGfxVersion11:
-			if (tiling->gfx9.swizzle != DC_SW_LINEAR) {
-				update_flags->bits.bandwidth_change = 1;
-				elevate_update_type(&update_type, UPDATE_TYPE_FULL, LOCK_DESCRIPTOR_GLOBAL);
-			}
-			break;
-		case DcGfxAddr3:
-			if (tiling->gfx_addr3.swizzle != DC_ADDR3_SW_LINEAR) {
-				update_flags->bits.bandwidth_change = 1;
-				elevate_update_type(&update_type, UPDATE_TYPE_FULL, LOCK_DESCRIPTOR_GLOBAL);
-			}
-			break;
-		case DcGfxVersion7:
-		case DcGfxVersion8:
-		case DcGfxVersionUnknown:
-		default:
-			break;
+		if (tiling->flags.avoid_full_update_on_tiling_change) {
+			elevate_update_type(&update_type, UPDATE_TYPE_MED, LOCK_DESCRIPTOR_STREAM);
+		} else {
+			update_flags->bits.bandwidth_change = 1;
+			elevate_update_type(&update_type, UPDATE_TYPE_FULL, LOCK_DESCRIPTOR_GLOBAL);
 		}
 	}
 
diff --git a/drivers/gpu/drm/amd/display/dc/dc_hw_types.h b/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
index cfa569a7bff1b..face23e0559d5 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
@@ -436,6 +436,10 @@ enum dc_gfxversion {
 			enum swizzle_mode_addr3_values swizzle;
 		} gfx_addr3;/*gfx with addr3 and above*/
 	};
+
+	struct {
+		bool avoid_full_update_on_tiling_change;
+	} flags;
 };
 
 /* Rotation angle */
-- 
2.53.0

[PATCH AUTOSEL 7.0] drm/amdgpu: fix array out of bounds accesses for mes sw_fini

[Sasha Levin]

From: Le Ma <le.ma@amd.com>

[ Upstream commit 418b4e397570f1b0ffb6d5c8aa0872bc33071d49 ]

The mes.fw[] is per-pipe resource shared accross xcc inst.
And enlarge hung_queue array to max inst_pipes.

Signed-off-by: Le Ma <le.ma@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a complete analysis. Let me
compile the findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: `drm/amdgpu` (AMD GPU DRM driver)
- **Action verb**: "fix" — explicitly a bug fix
- **Summary**: Fixes array out-of-bounds accesses in MES sw_fini path

Record: [drm/amdgpu] [fix] [Out-of-bounds array accesses in MES sw_fini
due to incorrect array sizing and indexing]

### Step 1.2: Tags
- **Signed-off-by**: Le Ma (author), Alex Deucher (AMD DRM maintainer)
- **Reviewed-by**: Hawking Zhang (AMD engineer/reviewer)
- No Fixes: tag, no Cc: stable, no Reported-by, no Link
- Absence of tags is expected for autoselection candidates

Record: Author is Le Ma (AMD engineer). Reviewed by Hawking Zhang.
Merged by Alex Deucher (AMD DRM maintainer). No syzbot or external
reporter.

### Step 1.3: Commit Body
The message states: "The mes.fw[] is per-pipe resource shared accross
xcc inst. And enlarge hung_queue array to max inst_pipes."

Two distinct bugs are described:
1. `mes.fw[]` is per-pipe (size 2) but was accessed with per-instance
   index (`inst = xcc_id * 2 + pipe`) → OOB when xcc_id > 0
2. `hung_queue_db_array_*` arrays were sized at `AMDGPU_MAX_MES_PIPES`
   (2) but accessed up to `AMDGPU_MAX_MES_INST_PIPES` (16) → OOB when
   num_xcc > 1

Record: Bug is OOB array access. Affects multi-xcc (multi-die) AMD GPU
configurations (e.g., MI300 series). The sw_fini path runs during driver
unload/cleanup.

### Step 1.4: Hidden Bug Fix Detection
This is explicitly labeled as a "fix" — no hiding here. Both are clear
out-of-bounds memory accesses.

Record: This is an explicit, clearly-described bug fix.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- `amdgpu_mes.h`: 3 lines changed (array size `AMDGPU_MAX_MES_PIPES` →
  `AMDGPU_MAX_MES_INST_PIPES`)
- `mes_v12_1.c`: 1 line removed, 3 lines added (move
  `amdgpu_ucode_release` call out of xcc loop)
- Total: +6/-4 lines — very small, surgical fix
- Functions modified: `mes_v12_1_sw_fini()`
- Scope: Single-subsystem, single-driver fix

### Step 2.2: Code Flow Change
**Hunk 1 (amdgpu_mes.h)**:
- Before: `hung_queue_db_array_*[AMDGPU_MAX_MES_PIPES]` — arrays of size
  2
- After: `hung_queue_db_array_*[AMDGPU_MAX_MES_INST_PIPES]` — arrays of
  size 16
- `amdgpu_mes_init()` and `amdgpu_mes_fini()` iterate `for (i = 0; i <
  AMDGPU_MAX_MES_PIPES * num_xcc; i++)` and access these arrays with
  index `i`. When num_xcc > 1, `i` exceeds 2.

**Hunk 2 (mes_v12_1.c)**:
- Before: `amdgpu_ucode_release(&adev->mes.fw[inst])` inside the
  xcc×pipe double loop, where `inst = xcc_id * AMDGPU_MAX_MES_PIPES +
  pipe` can be up to 15
- After: Separate loop `for (pipe = 0; pipe < AMDGPU_MAX_MES_PIPES;
  pipe++)` outside the xcc loop, using `pipe` (0 or 1) as index

### Step 2.3: Bug Mechanism
**Category**: Buffer overflow / out-of-bounds array access

Bug 1: `mes.fw[AMDGPU_MAX_MES_PIPES]` (size 2) accessed at index `inst`
(up to 15). This is OOB write/read during sw_fini.

Bug 2: `hung_queue_db_array_*[AMDGPU_MAX_MES_PIPES]` (size 2) accessed
at indices up to `AMDGPU_MAX_MES_PIPES * num_xcc - 1` (up to 15). OOB
access during init, fini, and hung queue detection.

### Step 2.4: Fix Quality
- Obviously correct: array sizing matches access patterns
- Minimal and surgical: no unrelated changes
- Regression risk: extremely low — just correcting array bounds and
  indexing
- The `fw[]` fix is semantically correct: firmware IS per-pipe, loaded
  via `amdgpu_mes_init_microcode()` which uses pipe index (verified in
  `amdgpu_mes.c` line 694)

Record: Fix quality is HIGH. Minimal risk of regression. Obviously
correct.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
- The buggy `sw_fini` function was introduced by `e220edf2d6fd6d`
  ("drm/amdgpu/mes_v12_1: initial support for mes_v12_1" by Jack Xiao,
  2025-05-14), which appeared in v7.0-rc1.
- The buggy `hung_queue_db_array_*` array declarations were introduced
  by `d09c7e266c8cd` ("drm/amdgpu/mes: add multi-xcc support" by Jack
  Xiao, 2024-11-21), also in v7.0-rc1.

### Step 3.2: No Fixes: tag present, but root cause commits identified
above.

### Step 3.3: File History
Related commits to `mes_v12_1.c` after initial creation:
- `a5192fbb2ee42`: "fix mes code error for muti-xcc" — different fix for
  different multi-xcc issues
- `75053887d6d8f`: "add cooperative dispatch support" — added
  `shared_cmd_buf_obj` arrays
- Multiple other features added during v7.0 development

### Step 3.4: Author
Le Ma is an AMD engineer who has contributed multiple amdgpu patches.
The fix was reviewed by Hawking Zhang and merged by Alex Deucher, the
AMD DRM maintainer.

### Step 3.5: Dependencies
No prerequisites beyond what's already in v7.0. The fix modifies only
existing code in a self-contained way.

---

## PHASE 4: MAILING LIST RESEARCH

The patch was found at `https://www.spinics.net/lists/amd-
gfx/msg138868.html`, submitted by Alex Deucher on March 6, 2026. It was
a single standalone patch (not part of a series). No objections or NAKs
found in the thread.

Record: No stable nomination in the mailing list discussion. No NAKs or
concerns raised.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Functions Modified
- `mes_v12_1_sw_fini()` — called during driver teardown/module unload

### Step 5.2: Callers of sw_fini
This is registered as the `sw_fini` callback in the amdgpu IP block
framework. It's called during:
- Module unload
- Driver teardown
- Error recovery paths

### Step 5.3: The OOB access in `amdgpu_mes_init()` /
`amdgpu_mes_fini()` (hung_queue arrays)
These are called during driver initialization and teardown — common
paths for any AMD GPU.

### Step 5.4: Reachability
The `hung_queue_db_array_*` OOB accesses are triggered on ANY multi-xcc
GPU (MI300 series) during normal driver init/fini. The `fw[]` OOB is
triggered during driver teardown on multi-xcc.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Which stable trees contain the buggy code?

| Stable Tree | mes_v12_1.c exists? | hung_queue arrays? | multi-xcc
MES? |
|-------------|--------------------|--------------------|---------------
-|
| v6.6        | NO                 | NO (not arrays)    | NO
|
| v6.12       | NO                 | NO                 | NO
|
| v6.19       | NO                 | Scalar, not arrays | NO
|
| **v7.0**    | **YES**            | **YES (buggy)**    | **YES**
|

**The buggy code exists ONLY in v7.0.** The `mes_v12_1.c` file was
created during the 7.0 development cycle. The `hung_queue_db_array_*`
arrays (with multi-xcc indexing) were introduced by `d09c7e266c8cd`
which is also 7.0-only.

### Step 6.2: Backport Complications
The fix should apply cleanly to 7.0.y since the code is identical.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem
- **drm/amdgpu** — AMD GPU driver. IMPORTANT subsystem: used by data
  center GPUs (MI300 series uses multi-xcc), desktop/workstation GPUs.
- Criticality: IMPORTANT (driver-specific but affects high-value
  enterprise hardware)

### Step 7.2: Activity
Extremely active subsystem with many recent commits.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who is affected?
Users with multi-xcc AMD GPUs (MI300 series, data center/AI
accelerators). The single-xcc path (num_xcc = 1) would not trigger the
OOB because `inst` maxes at 1.

### Step 8.2: Trigger conditions
- **hung_queue OOB**: Triggered during driver initialization
  (`amdgpu_mes_init`) — EVERY BOOT on multi-xcc hardware
- **fw[] OOB**: Triggered during driver teardown (`sw_fini`) — every
  module unload or error recovery

### Step 8.3: Failure mode severity
Out-of-bounds array access in kernel structures:
- Can corrupt adjacent struct members in `amdgpu_mes`
- Can cause kernel oops/panic from corrupted pointers
- Severity: **CRITICAL** (memory corruption, potential crash, affects
  every boot on affected hardware)

### Step 8.4: Risk-Benefit Ratio
- **Benefit**: HIGH — prevents memory corruption and potential crashes
  on multi-xcc AMD GPUs
- **Risk**: VERY LOW — 10 lines, obviously correct array sizing and
  indexing fix
- **Ratio**: Very favorable

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting:**
- Fixes real OOB array accesses (memory corruption)
- Triggered on every boot/shutdown of multi-xcc AMD GPUs
- Small, surgical fix (+6/-4 lines)
- Obviously correct: array sizing matches access patterns
- Reviewed by AMD maintainer (Hawking Zhang)
- Merged by subsystem maintainer (Alex Deucher)
- Self-contained, no dependencies

**AGAINST backporting:**
- Only applicable to 7.0.y (no older stable trees have this code)
- Only affects multi-xcc configurations (MI300 series)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** — array sizing fix is trivially
   verifiable
2. Fixes a real bug? **YES** — OOB array access causing memory
   corruption
3. Important issue? **YES** — memory corruption, potential kernel crash
4. Small and contained? **YES** — 10 lines across 2 files in same driver
5. No new features? **YES** — pure bug fix
6. Can apply to stable? **YES** — 7.0.y only, should apply cleanly

### Step 9.3: Exception categories
Not an exception category — this is a standard bug fix.

### Step 9.4: Decision
This is a clear bug fix for out-of-bounds array accesses that cause
memory corruption on multi-xcc AMD GPUs. The fix is small, obvious, and
well-reviewed. It should be backported to the 7.0.y stable tree.

---

## Verification

- [Phase 1] Parsed tags: Signed-off-by Le Ma (author), Reviewed-by
  Hawking Zhang, Signed-off-by Alex Deucher (maintainer)
- [Phase 2] Diff analysis: 3 lines in header change array sizes, 4 lines
  in .c restructure fw release loop. Total +6/-4.
- [Phase 2] Confirmed `fw[]` declared as `AMDGPU_MAX_MES_PIPES` (size 2)
  at amdgpu_mes.h:98
- [Phase 2] Confirmed `fw[]` loaded per-pipe in `amdgpu_mes.c:694` using
  pipe index (0 or 1)
- [Phase 2] Confirmed `hung_queue_db_array_*` accessed at index up to
  `AMDGPU_MAX_MES_PIPES * num_xcc` in `amdgpu_mes.c:220,266`
- [Phase 2] Confirmed `AMDGPU_MAX_MES_PIPES = 2`,
  `AMDGPU_MAX_GC_INSTANCES = 8`, `AMDGPU_MAX_MES_INST_PIPES = 16`
- [Phase 3] git blame: `sw_fini` introduced by `e220edf2d6fd6d`
  (v7.0-rc1), hung_queue arrays by `d09c7e266c8cd` (v7.0-rc1)
- [Phase 3] git tag --contains: both commits only in v7.0-rc1, v7.0
- [Phase 3] git show v6.19: `mes_v12_1.c` does not exist;
  `hung_queue_db_array_*` are scalar not arrays; no
  `AMDGPU_MAX_MES_INST_PIPES` macro
- [Phase 3] git show v6.12, v6.6: none of this code exists
- [Phase 4] Found patch on spinics.net amd-gfx list (March 6, 2026),
  standalone patch, no objections
- [Phase 5] `sw_fini` is IP block teardown callback, called during
  driver unload
- [Phase 5] `amdgpu_mes_init()`/`amdgpu_mes_fini()` access hung_queue
  arrays with multi-xcc indices
- [Phase 6] Buggy code exists ONLY in v7.0 tree — not in v6.19, v6.12,
  or v6.6
- [Phase 8] Failure mode: OOB memory access → memory corruption →
  potential kernel crash. Severity CRITICAL on multi-xcc hardware.

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h | 6 +++---
 drivers/gpu/drm/amd/amdgpu/mes_v12_1.c  | 4 +++-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h
index bcf2a067dc410..f80e3aca9c78e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h
@@ -159,9 +159,9 @@ struct amdgpu_mes {
 
 	int				hung_queue_db_array_size;
 	int				hung_queue_hqd_info_offset;
-	struct amdgpu_bo		*hung_queue_db_array_gpu_obj[AMDGPU_MAX_MES_PIPES];
-	uint64_t			hung_queue_db_array_gpu_addr[AMDGPU_MAX_MES_PIPES];
-	void				*hung_queue_db_array_cpu_addr[AMDGPU_MAX_MES_PIPES];
+	struct amdgpu_bo		*hung_queue_db_array_gpu_obj[AMDGPU_MAX_MES_INST_PIPES];
+	uint64_t			hung_queue_db_array_gpu_addr[AMDGPU_MAX_MES_INST_PIPES];
+	void				*hung_queue_db_array_cpu_addr[AMDGPU_MAX_MES_INST_PIPES];
 
 	/* cooperative dispatch */
 	bool                enable_coop_mode;
diff --git a/drivers/gpu/drm/amd/amdgpu/mes_v12_1.c b/drivers/gpu/drm/amd/amdgpu/mes_v12_1.c
index 7b8c670d0a9ed..d8e4b52bdfd50 100644
--- a/drivers/gpu/drm/amd/amdgpu/mes_v12_1.c
+++ b/drivers/gpu/drm/amd/amdgpu/mes_v12_1.c
@@ -1611,7 +1611,6 @@ static int mes_v12_1_sw_fini(struct amdgpu_ip_block *ip_block)
 			amdgpu_bo_free_kernel(&adev->mes.eop_gpu_obj[inst],
 					      &adev->mes.eop_gpu_addr[inst],
 					      NULL);
-			amdgpu_ucode_release(&adev->mes.fw[inst]);
 
 			if (adev->enable_uni_mes || pipe == AMDGPU_MES_SCHED_PIPE) {
 				amdgpu_bo_free_kernel(&adev->mes.ring[inst].mqd_obj,
@@ -1622,6 +1621,9 @@ static int mes_v12_1_sw_fini(struct amdgpu_ip_block *ip_block)
 		}
 	}
 
+	for (pipe = 0; pipe < AMDGPU_MAX_MES_PIPES; pipe++)
+		amdgpu_ucode_release(&adev->mes.fw[pipe]);
+
 	for (xcc_id = 0; xcc_id < num_xcc; xcc_id++) {
 		if (!adev->enable_uni_mes) {
 			amdgpu_bo_free_kernel(&adev->gfx.kiq[xcc_id].ring.mqd_obj,
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] drm/amd/display: Exit IPS w/ DC helper for all dc_set_power_state cases

[Sasha Levin]

From: Ovidiu Bunea <ovidiu.bunea@amd.com>

[ Upstream commit f44c094449669c7d9ac403cc73ce23e255f0828b ]

[why & how]
On D3 path during dc_set_power_state, we may be in idle_allowed=true,
at which point we will exit idle via dc_wake_and_execute_dmub_cmd_list
which doesn't update dc->idle_optimizations_allowed to false. This
would cause any future attempts to allow idle optimizations via the DC
helper to get skipped because the value is stale and not reflective of
the actual HW state.

Move dc_exit_ips_for_hw_access() to the top of the function.
Additionally ensure that dc_power_down_on_boot thread holds the DC
lock and only runs if there are 0 streams.

Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Ovidiu Bunea <ovidiu.bunea@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Good - the code matches the "before" state of the diff perfectly. The
patch would apply cleanly to this tree.

Now let me complete the final analysis phases with a comprehensive
synthesis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
Record: [drm/amd/display] [Exit/Move] Fix stale IPS idle state tracking
in dc_set_power_state and dc_power_down_on_boot.

**Step 1.2: Tags**
- Reviewed-by: Nicholas Kazlauskas (he's the original author of
  `dc_exit_ips_for_hw_access`, a key AMD display engineer)
- Signed-off-by: Ovidiu Bunea (patch author, AMD display developer)
- Signed-off-by: Ivan Lipski (submitter, AMD display)
- Tested-by: Dan Wheeler (AMD QA)
- Signed-off-by: Alex Deucher (AMD GPU subsystem maintainer)
- No Fixes: tag, no Cc: stable, no Reported-by: - expected for this
  review pipeline.

**Step 1.3: Commit Body**
The commit clearly describes a state inconsistency bug: On the D3 power-
down path, if `idle_allowed=true`, the system exits idle via
`dc_wake_and_execute_dmub_cmd_list` which does NOT update
`dc->idle_optimizations_allowed` to false. This leaves a stale value.
Any future attempt to call `dc_allow_idle_optimizations(dc, false)` gets
skipped at line 5714 (`if (allow == dc->idle_optimizations_allowed)
return;`) because the stale value says it's already false, when the HW
actually re-entered idle.

**Step 1.4: Hidden Bug Fix**
This IS a bug fix. The commit message is explicit about the bug
mechanism: stale state causes future IPS exits to be skipped. This can
lead to register access while the hardware is in a power-gated/idle
state, which can cause hangs, corruption, or crashes.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Single file: `drivers/gpu/drm/amd/display/dc/core/dc.c`
- ~6 lines changed net (moved `dc_exit_ips_for_hw_access` before switch,
  added stream_count guard)
- Functions modified: `dc_power_down_on_boot`, `dc_set_power_state`

**Step 2.2: Code Flow Change**
1. In `dc_set_power_state`: `dc_exit_ips_for_hw_access(dc)` moved from
   inside D0 case to before the switch statement. This ensures ALL power
   state transitions (D0, D3, default) exit IPS cleanly via the DC
   helper that properly updates `dc->idle_optimizations_allowed`.
2. In `dc_power_down_on_boot`: Added `stream_count > 0` early return
   guard to prevent power_down_on_boot from running when there are
   active streams (safety check, holds DC lock).

**Step 2.3: Bug Mechanism**
Category: **State inconsistency / stale flag bug**. The D3 path calls
`dc_dmub_srv_notify_fw_dc_power_state` which internally calls
`dc_wake_and_execute_dmub_cmd_list`. That function uses
`dc_dmub_srv_apply_idle_power_optimizations(ctx->dc, false)` which sets
`dc_dmub_srv->idle_allowed = false` but does NOT update
`dc->idle_optimizations_allowed`. When `dc_exit_ips_for_hw_access`
(which calls `dc_allow_idle_optimizations_internal`) is NOT called on D3
path, `dc->idle_optimizations_allowed` stays `true` (stale). On
subsequent resume, the guard `if (allow ==
dc->idle_optimizations_allowed) return;` at line 5714 prevents the real
IPS exit from happening.

**Step 2.4: Fix Quality**
- The fix is small, surgical, and obviously correct.
- Moving IPS exit before the switch is safe: for D0, it was already
  there (just earlier now); for D3, it's newly added; for default, it's
  newly covered.
- The `dc_exit_ips_for_hw_access` is a no-op when IPS is not supported
  (checks `dc->caps.ips_support`).
- The stream_count guard in `dc_power_down_on_boot` is a defensive check
  that prevents powering down when displays are active.
- Regression risk: LOW. The IPS exit is idempotent and already called on
  D0. Adding it before the switch just expands coverage.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
- `dc_set_power_state` core structure dates back to commit
  `4562236b3bc0a2` (Harry Wentland, 2017) - very old, stable code.
- `dc_exit_ips_for_hw_access` was added to D0 path by `a9b1a4f684b32b`
  (Nicholas Kazlauskas, 2024-01-16) - tagged "Cc: stable@vger.kernel.org
  # 6.1+"
- The D3 case was added by `2ee27baf5c7cba` (Duncan Ma, 2025-03-31) -
  first in v6.17-rc1. This commit introduced the D3-specific path that
  triggers the bug.

**Step 3.2: Fixes tag**
No Fixes: tag. However, the bug is clearly introduced by
`2ee27baf5c7cba` (D3 path) combined with `a9b1a4f684b32b` (IPS exit only
in D0).

**Step 3.3: File history**
The file is actively developed. The current tree state matches the diff
context exactly.

**Step 3.4: Author**
Ovidiu Bunea is a regular AMD display developer. Reviewed by Nicholas
Kazlauskas who is a key AMD display engineer and the original author of
IPS support.

**Step 3.5: Dependencies**
Requires `2ee27baf5c7cba` (D3 case in dc_set_power_state) to be present.
This commit was first in v6.17-rc1. In the 7.0 tree, this is already
present.

## PHASE 4: MAILING LIST RESEARCH

b4 dig failed to find matching threads for both the IPS exit commit and
the D3 notification commit (AMD display patches often go through
internal AMD submission channels). No lore discussion available.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions modified**: `dc_power_down_on_boot`,
`dc_set_power_state`

**Step 5.2: Callers**
- `dc_set_power_state` is called from `dm_suspend` (D3) and `dm_resume`
  (D0) in `amdgpu_dm.c` - these are the primary suspend/resume paths for
  ALL AMD GPUs.
- `dc_power_down_on_boot` - called during initial boot for display power
  management.

**Step 5.3-5.4: Call chain**
Suspend/resume is a hot user-facing path. Every AMD GPU user hits this
on laptop suspend/resume, hibernate, and S0ix entry/exit.

**Step 5.5: Similar patterns**
The `dc_exit_ips_for_hw_access` call is a common pattern throughout AMD
display code - it's used in `dc_stream.c`, `dc_surface.c`, and many
places in `dc.c`.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy code existence**
- The D3 path (`2ee27baf5c7cba`) was first introduced in v6.17-rc1.
- The IPS exit (`a9b1a4f684b32b`) has been marked Cc: stable 6.1+.
- The bug requires BOTH commits to be present. For stable trees <= 6.12,
  the D3 path doesn't exist, so the specific bug doesn't trigger there.
- For stable 7.0 tree: both commits are present, bug can trigger.

**Step 6.2: Backport complications**
The patch applies cleanly to the 7.0 tree (verified by comparing the
current code state with the diff context).

## PHASE 7: SUBSYSTEM CONTEXT

- Subsystem: drm/amd/display - GPU display driver
- Criticality: IMPORTANT - AMD GPUs are in millions of laptops and
  desktops. Suspend/resume is critical for laptop users.
- IPS (Idle Power State) affects DCN35+ hardware (recent AMD APUs in
  laptops).

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who is affected**
All users of AMD APUs with DCN35+ display hardware (IPS support) - this
includes recent AMD Ryzen laptops.

**Step 8.2: Trigger conditions**
Any suspend/resume cycle to D3 state when IPS is enabled
(idle_allowed=true). This is a common, everyday operation on laptops.

**Step 8.3: Failure mode**
The stale `idle_optimizations_allowed` flag means subsequent IPS exit
calls get skipped. This means hardware register accesses can happen
while the hardware is power-gated, leading to:
- Display hangs
- System hangs on resume
- Potential display corruption
Severity: **HIGH** (system hang/display hang on resume)

**Step 8.4: Risk-Benefit Ratio**
- BENEFIT: HIGH - prevents display/system hangs on suspend/resume for
  AMD laptop users
- RISK: LOW - ~6 lines changed, moving an existing call earlier and
  adding a defensive guard
- The fix is obviously correct, reviewed by the IPS subsystem expert,
  and tested by AMD QA

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Fixes a real state inconsistency bug that causes stale IPS idle
  tracking
- Triggers on every D3 suspend path for AMD APUs with IPS support (very
  common)
- Failure mode is display/system hang on resume (HIGH severity)
- Small, surgical fix (~6 lines), single file
- Reviewed by Nicholas Kazlauskas (IPS expert), tested by AMD QA
- Applies cleanly to the 7.0 tree
- The parent commit `a9b1a4f684b32b` was already explicitly nominated
  for stable (Cc: stable 6.1+)

**Evidence AGAINST backporting:**
- No Fixes: tag (expected)
- No syzbot/user bug reports linked (AMD internal finding)
- The D3 path dependency (`2ee27baf5c7cba`) is only in v6.17+, limiting
  which stable trees need this

**Stable Rules Checklist:**
1. Obviously correct and tested? YES - reviewed by IPS expert, tested by
   AMD QA
2. Fixes a real bug? YES - stale state causes IPS exits to be skipped
3. Important issue? YES - display/system hang on suspend/resume
4. Small and contained? YES - ~6 lines, single file
5. No new features? CORRECT - no new features
6. Can apply to stable? YES - applies cleanly to 7.0

## Verification

- [Phase 1] Parsed tags: Reviewed-by Nicholas Kazlauskas (IPS author),
  Tested-by Dan Wheeler (AMD QA), Signed-off-by Alex Deucher
  (maintainer)
- [Phase 2] Diff: ~6 lines changed in dc.c, moves
  dc_exit_ips_for_hw_access before switch, adds stream_count guard
- [Phase 2] Traced bug mechanism: dc_wake_and_execute_dmub_cmd_list sets
  dc_dmub_srv->idle_allowed but NOT dc->idle_optimizations_allowed,
  confirmed at lines 1728-1730 and 1694 of dc_dmub_srv.c, and guard at
  line 5714 of dc.c
- [Phase 3] git blame: D3 path introduced by 2ee27baf5c7cba (v6.17-rc1),
  IPS exit by a9b1a4f684b32b (v6.9-rc1, Cc: stable 6.1+)
- [Phase 3] Confirmed 2ee27baf5c7cba is in v7.0 tree (git merge-base
  --is-ancestor)
- [Phase 3] Confirmed a9b1a4f684b32b is in v7.0 tree (git merge-base
  --is-ancestor)
- [Phase 4] b4 dig failed for both parent commits (AMD internal
  submission path)
- [Phase 5] dc_set_power_state called from dm_suspend/dm_resume - common
  laptop suspend/resume path
- [Phase 6] Current tree code matches diff context exactly - clean apply
  expected
- [Phase 6] Bug requires D3 path (v6.17+) - applicable to 7.0 stable
  tree
- [Phase 8] Failure mode: stale idle flag -> skipped IPS exit ->
  register access while power-gated -> hang. Severity HIGH.
- UNVERIFIED: Could not find mailing list discussion (b4 dig returned no
  results). Decision not affected since the code analysis is conclusive.

The fix is small, surgical, addresses a clear state-tracking bug in AMD
display's IPS handling that affects suspend/resume on common AMD laptop
hardware, and meets all stable kernel criteria.

**YES**

 drivers/gpu/drm/amd/display/dc/core/dc.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 3e87b6a553be9..4c5ecbb97d5b0 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -5540,6 +5540,9 @@ void dc_power_down_on_boot(struct dc *dc)
 {
 	if (dc->ctx->dce_environment != DCE_ENV_VIRTUAL_HW &&
 	    dc->hwss.power_down_on_boot) {
+		if (dc->current_state->stream_count > 0)
+			return;
+
 		if (dc->caps.ips_support)
 			dc_exit_ips_for_hw_access(dc);
 		dc->hwss.power_down_on_boot(dc);
@@ -5551,12 +5554,12 @@ void dc_set_power_state(struct dc *dc, enum dc_acpi_cm_power_state power_state)
 	if (!dc->current_state)
 		return;
 
+	dc_exit_ips_for_hw_access(dc);
+
 	switch (power_state) {
 	case DC_ACPI_CM_POWER_STATE_D0:
 		dc_state_construct(dc, dc->current_state);
 
-		dc_exit_ips_for_hw_access(dc);
-
 		dc_z10_restore(dc);
 
 		dc_dmub_srv_notify_fw_dc_power_state(dc->ctx->dmub_srv, power_state);
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] drm/amdgpu: fix syncobj leak for amdgpu_gem_va_ioctl()

[Sasha Levin]

From: Prike Liang <Prike.Liang@amd.com>

[ Upstream commit a0f0b6d31a53a7607ed44f7623faafc628333258 ]

It requires freeing the syncobj and chain
alloction resource.

Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The 7.0 tree doesn't have `(!adev->debug_vm || timeline_syncobj)` — it
has `!adev->debug_vm`. This confirms the diff was created against a
newer mainline. The fix's core logic still applies.

---

## Complete Analysis

### PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `drm/amdgpu`
- Action verb: "fix"
- Summary: Fix syncobj and chain allocation resource leak in
  amdgpu_gem_va_ioctl()
- Record: [drm/amdgpu] [fix] [syncobj/chain resource leak in gem VA
  ioctl]

**Step 1.2: Tags**
- `Reviewed-by: Christian König <christian.koenig@amd.com>` — subsystem
  co-maintainer
- `Signed-off-by: Alex Deucher <alexander.deucher@amd.com>` — AMD GPU
  maintainer committed it
- `Signed-off-by: Prike Liang <Prike.Liang@amd.com>` — AMD engineer,
  author
- No Fixes: tag, no Reported-by:, no Cc: stable — expected for manual
  review candidates
- Record: Reviewed by Christian König (DRM/amdgpu co-maintainer).
  Committed by Alex Deucher.

**Step 1.3: Commit Body**
- Describes: "requires freeing the syncobj and chain allocation
  resource"
- Bug: syncobj refcount and chain memory are never released after use
- Failure mode: resource/memory leak on every ioctl call with timeline
  syncobj
- Record: Clear resource leak. Every call to the ioctl with timeline
  syncobj leaks memory.

**Step 1.4: Hidden Bug Fixes**
- This is NOT hidden — it explicitly says "fix...leak"
- Record: Explicit bug fix.

### PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Files: `drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c` only
- Changes: +5 lines added (3 in ioctl cleanup, 1 NULL assignment in
  helper, 1 NULL assignment in ioctl)
- Functions modified: `amdgpu_gem_update_timeline_node()` and
  `amdgpu_gem_va_ioctl()`
- Record: Single-file surgical fix, 5 meaningful lines added.

**Step 2.2: Code Flow Changes**

Hunk 1 — `amdgpu_gem_update_timeline_node()`:
- BEFORE: When `dma_fence_chain_alloc()` fails, calls
  `drm_syncobj_put(*syncobj)` and returns -ENOMEM, leaving `*syncobj` as
  a dangling pointer.
- AFTER: Also sets `*syncobj = NULL` to prevent dangling pointer.

Hunk 2 — `amdgpu_gem_va_ioctl()`:
- BEFORE: After `drm_syncobj_add_point()` consumes `timeline_chain`,
  `timeline_chain` still points to consumed memory. The `error:` label
  never frees `timeline_chain` or puts `timeline_syncobj`.
- AFTER: Sets `timeline_chain = NULL` after consumption. Adds
  `dma_fence_chain_free(timeline_chain)` and
  `drm_syncobj_put(timeline_syncobj)` to cleanup.

**Step 2.3: Bug Mechanism**
- Category: **Resource leak** (syncobj refcount leak + memory leak)
- `drm_syncobj_find()` increments refcount — never decremented by caller
- `dma_fence_chain_alloc()` allocates memory — never freed when not
  consumed
- Record: Missing cleanup for refcounted object and allocated memory on
  both success and error paths.

**Step 2.4: Fix Quality**
- Obviously correct: adds standard cleanup patterns (NULL-after-consume,
  free/put at error label)
- Minimal and surgical: 5 meaningful lines
- No regression risk: `dma_fence_chain_free(NULL)` = `kfree(NULL)` is
  safe; `drm_syncobj_put` is guarded by NULL check
- Record: High quality, zero regression risk.

### PHASE 3: GIT HISTORY

**Step 3.1: Blame**
- `amdgpu_gem_update_timeline_node` — introduced by `70773bef4e091f`
  (Arvind Yadav, Sep 2024)
- Timeline call moved before switch by `ad6c120f688803` (Feb 2025, "fix
  the memleak caused by fence not released")
- Inline timeline handling in ioctl by `bd8150a1b3370` (Dec 2025, v4
  refactor)
- Record: Buggy code introduced in 70773bef4e091f, worsened by
  ad6c120f688803 which moved allocation before switch but didn't add
  cleanup.

**Step 3.2: Fixes tag**
- No Fixes: tag present. Based on analysis, the bug was introduced in
  `70773bef4e091f` and never had proper cleanup.
- Record: Bug exists since original timeline code introduction.

**Step 3.3: File History**
- 31 commits since `ad6c120f688803`. Active file with many recent
  changes.
- The v4 refactor (`bd8150a1b3370`) and v7 refactor (`efdc66fe12b07`)
  touched the same code but neither added cleanup.
- Record: Standalone fix, no prerequisites beyond code already in 7.0
  tree.

**Step 3.4: Author**
- Prike Liang: AMD engineer, regular contributor to amdgpu driver with
  multiple recent fixes.
- Record: Active AMD GPU developer, credible author.

**Step 3.5: Dependencies**
- None. The fix only adds cleanup to existing code paths. All referenced
  functions exist in 7.0.
- Minor context conflict: mainline has `(!adev->debug_vm ||
  timeline_syncobj)` vs 7.0's `!adev->debug_vm`, but the fix's added
  lines don't depend on this condition.
- Record: Standalone fix, minor context adjustment needed.

### PHASE 4: MAILING LIST RESEARCH

**Step 4.1-4.5:**
- b4 dig could not find the original patch submission (lore.kernel.org
  blocked by Anubis).
- The related commit `ad6c120f688803` explicitly described the memleak
  problem with a full stack trace showing BUG in drm_sched_fence slab
  during module unload — evidence the leak has real impact.
- Christian König (co-maintainer) reviewed the fix.
- Record: Could not access lore. However, reviewer is the subsystem co-
  maintainer, which is strong endorsement.

### PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.4:**
- `amdgpu_gem_va_ioctl()` is a DRM ioctl handler directly callable from
  userspace
- Called every time userspace maps/unmaps GPU virtual address space
- This is a HOT path for GPU applications (Mesa, AMDVLK, ROCm)
- Every call with a timeline syncobj leaks the syncobj refcount and
  potentially the chain allocation
- Record: Ioctl path reachable from any GPU userspace application. Very
  high call frequency.

### PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The buggy code exists in 7.0 tree. Confirmed via blame:
`70773bef4e091f` (Sep 2024) and `ad6c120f688803` (Feb 2025) are both
present.

**Step 6.2:** Minor context conflict due to condition difference in line
979. Would need a trivial backport adjustment, or `git apply --3way`
could handle it.

**Step 6.3:** No related fix already in stable for this specific leak.

### PHASE 7: SUBSYSTEM CONTEXT

- Subsystem: `drivers/gpu/drm/amd/amdgpu` — GPU driver
- Criticality: IMPORTANT — AMD GPUs are extremely common in desktops,
  servers, and workstations
- Active subsystem with frequent changes
- Record: [IMPORTANT] AMD GPU driver, widely used hardware.

### PHASE 8: IMPACT AND RISK

**Step 8.1:** Affected users: All users with AMD GPUs using
userqueue/timeline syncobj features (Mesa Vulkan, ROCm).

**Step 8.2:** Trigger: Any GPU application calling the VA ioctl with a
timeline syncobj. Repeated calls (normal GPU operation) cause cumulative
memory leak.

**Step 8.3:** Failure mode: Memory leak in hot ioctl path → eventual OOM
under sustained GPU workloads. Severity: **HIGH** (gradual resource
exhaustion).

**Step 8.4:**
- BENEFIT: High — prevents memory leak in frequently-called GPU ioctl
- RISK: Very low — 5-line fix adding standard NULL-and-free patterns,
  reviewed by subsystem maintainer
- Record: High benefit, very low risk.

### PHASE 9: SYNTHESIS

**Evidence FOR backporting:**
- Fixes a real resource leak (syncobj refcount + chain memory) in a
  userspace-facing ioctl
- Every call with timeline syncobj leaks resources — cumulative, leads
  to OOM under sustained use
- Small, surgical fix: 5 meaningful lines in a single file
- Reviewed by Christian König (DRM/amdgpu co-maintainer)
- Obviously correct: standard cleanup patterns (NULL-after-consume,
  free/put at cleanup label)
- Bug code exists in 7.0 tree (confirmed via blame)
- Zero regression risk: `kfree(NULL)` is safe, NULL checks guard all
  puts

**Evidence AGAINST backporting:**
- Minor context conflict (condition text differs between mainline and
  7.0) — trivially resolvable
- Timeline syncobj feature is relatively new (Sep 2024) — may not affect
  all users yet

**Stable rules checklist:**
1. Obviously correct and tested? **YES** — standard cleanup pattern,
   reviewed by co-maintainer
2. Fixes a real bug? **YES** — resource leak in ioctl path
3. Important issue? **YES** — memory leak in hot path → eventual OOM
4. Small and contained? **YES** — 5 lines, single file
5. No new features? **YES** — only adds missing cleanup
6. Can apply to stable? **YES** — with minor context adjustment

### Verification

- [Phase 1] Parsed tags: Reviewed-by Christian König (co-maintainer),
  SOB Alex Deucher (maintainer)
- [Phase 2] Diff analysis: 5 lines added — NULL assignment in helper
  error path, NULL assignment after chain consumption, 3-line cleanup in
  error label (chain free + syncobj put)
- [Phase 3] git blame: timeline code introduced in 70773bef4e091f (Sep
  2024), moved by ad6c120f688803 (Feb 2025), both in 7.0 tree
- [Phase 3] git show ad6c120f688803: confirmed this commit moved
  timeline allocation before switch without adding cleanup — the root
  cause
- [Phase 3] git show bd8150a1b3370: v4 refactor inlined timeline
  handling, still no cleanup
- [Phase 3] git show efdc66fe12b07: v7 refactor, still no cleanup
- [Phase 5] amdgpu_gem_va_ioctl is DRM ioctl handler — directly callable
  from userspace, hot path for GPU apps
- [Phase 5] Confirmed drm_syncobj_add_point() consumes chain
  (dma_fence_chain_init + rcu_assign_pointer), so NULL-after-use is
  correct
- [Phase 5] Confirmed dma_fence_chain_free(NULL) is safe (just
  kfree(NULL))
- [Phase 6] Verified no drm_syncobj_put(timeline_syncobj) in current 7.0
  file — bug confirmed present
- [Phase 6] Minor context conflict: 7.0 has `!adev->debug_vm`, mainline
  has `(!adev->debug_vm || timeline_syncobj)` — needs trivial adjustment
- [Phase 8] Failure mode: cumulative memory/refcount leak → eventual
  OOM, severity HIGH
- UNVERIFIED: Could not access lore.kernel.org for original patch
  discussion (blocked by Anubis)

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index c4839cf2dce37..3f95aca700264 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -107,6 +107,7 @@ amdgpu_gem_update_timeline_node(struct drm_file *filp,
 	*chain = dma_fence_chain_alloc();
 	if (!*chain) {
 		drm_syncobj_put(*syncobj);
+		*syncobj = NULL;
 		return -ENOMEM;
 	}
 
@@ -983,6 +984,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
 						      timeline_chain,
 						      fence,
 						      args->vm_timeline_point);
+				timeline_chain = NULL;
 			}
 		}
 		dma_fence_put(fence);
@@ -990,6 +992,9 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
 	}
 
 error:
+	dma_fence_chain_free(timeline_chain);
+	if (timeline_syncobj)
+		drm_syncobj_put(timeline_syncobj);
 	drm_exec_fini(&exec);
 error_put_gobj:
 	drm_gem_object_put(gobj);
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] drm/amdgpu: Check for multiplication overflow in checkpoint stack size

[Sasha Levin]

From: David Francis <David.Francis@amd.com>

[ Upstream commit 421c0f19043337a553e802b2dfe4b56d538ef4d6 ]

get_checkpoint_info() in kfd_mqd_manager_v9.c finds 32-bit value
ctl_stack_size by multiplying two 32-bit values. This can overflow to a
lower value, which could result in copying outside the bounds of
a buffer in checkpoint_mqd() in the same file.

Put in a check for the overflow, and fail with -EINVAL if detected.

v2: use check_mul_overflow()

Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a complete picture. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `drm/amdgpu` (AMD GPU driver, KFD subsystem)
- Action verb: "Check" (adding a missing safety check)
- Summary: Add overflow check to prevent out-of-bounds copy in
  checkpoint stack size computation

**Step 1.2: Tags**
- Signed-off-by: David Francis (author)
- Reviewed-by: Alex Deucher (AMD DRM subsystem maintainer)
- Signed-off-by: Alex Deucher (committer/maintainer)
- No Fixes: tag (expected for autosel candidates)
- No Cc: stable (expected)
- No Reported-by (found by code inspection, not a crash report)

**Step 1.3: Commit Body**
- Bug: `get_checkpoint_info()` computes `ctl_stack_size` by multiplying
  two 32-bit values (`m->cp_hqd_cntl_stack_size *
  NUM_XCC(mm->dev->xcc_mask)`). This can overflow to a smaller value.
- Consequence: The overflowed smaller value is used to size a buffer
  allocation. Later, `checkpoint_mqd()` copies data using the actual
  (non-overflowed) hardware values, writing beyond the buffer boundary.
- Failure mode: Out-of-bounds memory write (buffer overflow)
- Fix: Use `check_mul_overflow()` and return -EINVAL on overflow

**Step 1.4: Hidden Bug Fix Detection**
This is explicitly a bug fix for a buffer overflow vulnerability. The v2
notation indicates the fix went through review iteration.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 6 files changed: `kfd_device_queue_manager.c`,
  `kfd_device_queue_manager.h`, `kfd_mqd_manager.h`,
  `kfd_mqd_manager_v9.c`, `kfd_mqd_manager_vi.c`,
  `kfd_process_queue_manager.c`
- Net change: +22/-8 lines
- Functions modified: `get_checkpoint_info` (v9 and vi),
  `get_queue_checkpoint_info` (dqm), `pqm_get_queue_checkpoint_info`
- Scope: Multi-file but contained - all changes serve a single purpose
  (propagating error from overflow check)

**Step 2.2: Code Flow Change**
- Core fix in `kfd_mqd_manager_v9.c`: replaces unchecked multiplication
  with `check_mul_overflow()`, returning -EINVAL on overflow
- Plumbing: `get_checkpoint_info` and `get_queue_checkpoint_info`
  signatures changed from `void` to `int` to propagate the error
- `kfd_mqd_manager_vi.c`: trivially updated to return 0 (no overflow
  risk since `*ctl_stack_size = 0`)
- `kfd_process_queue_manager.c`: now checks the return value and
  propagates errors

**Step 2.3: Bug Mechanism**
Category: **Buffer overflow / out-of-bounds write**

The flow is:
1. `get_checkpoint_info()` computes `ctl_stack_size =
   m->cp_hqd_cntl_stack_size * NUM_XCC(...)` - can overflow to a small
   value
2. `criu_checkpoint_queues_device()` uses this to allocate a buffer:
   `kzalloc(sizeof(*q_data) + mqd_size + ctl_stack_size, ...)`
3. `checkpoint_mqd_v9_4_3()` loops over each XCC and calls
   `memcpy(ctl_stack_dst, ctl_stack, m->cp_hqd_cntl_stack_size)` for
   each, writing the full actual size
4. Total bytes written = `m->cp_hqd_cntl_stack_size * NUM_XCC(...)` (the
   actual, non-overflowed product), exceeding the buffer

**Step 2.4: Fix Quality**
- Obviously correct: uses standard `check_mul_overflow()` kernel macro
- Minimal/surgical: core logic is 3 lines; rest is necessary type
  signature propagation
- No regression risk: overflow case now fails gracefully with -EINVAL
  instead of silently corrupting memory
- Reviewed by subsystem maintainer Alex Deucher

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
- `get_checkpoint_info` was introduced by commit 3a9822d7bd623b (David
  Yat Sin, 2021-01-25) for CRIU checkpoint support
- The multiplication `* NUM_XCC(...)` was added by commit f6c0f3d24478a0
  / a578f2a58c3ab (David Yat Sin, 2025-07-16) "Fix checkpoint-restore on
  multi-xcc"
- The multi-xcc fix was merged in v6.18 and was cherry-picked with `Cc:
  stable@vger.kernel.org`

**Step 3.2: Fixes tag** - No Fixes: tag present, which is expected.

**Step 3.3: File History** - The file is actively developed with 30+
changes since v6.6.

**Step 3.4: Author** - David Francis is an AMD employee working on
KFD/CRIU support.

**Step 3.5: Dependencies** - This commit is standalone. It only changes
the existing code path without requiring other patches.

## PHASE 4: MAILING LIST

- Original submission found at spinics.net/lists/amd-gfx/msg138647.html
  (posted 2026-03-04)
- v2 iteration used `check_mul_overflow()` (v1 presumably used manual
  overflow checks)
- Alex Deucher provided Reviewed-by (msg138731)
- No NAKs or concerns raised
- No explicit stable nomination by reviewers, but the fix targets a bug
  in code that was itself `Cc: stable`

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Key Functions**
- `get_checkpoint_info()` in v9 (core fix)
- `get_queue_checkpoint_info()` in dqm (plumbing)
- `pqm_get_queue_checkpoint_info()` (plumbing)

**Step 5.2: Callers**
- `pqm_get_queue_checkpoint_info()` -> `get_queue_data_sizes()` ->
  `criu_checkpoint_queues_device()` -> `kfd_process_get_queue_info()`
- Called during CRIU checkpoint operations (process migration/save)

**Step 5.4: Reachability**
The path is reachable from userspace through the KFD ioctl interface
during CRIU operations. On multi-XCC AMD GPUs, if
`cp_hqd_cntl_stack_size` is large enough, the multiplication overflows.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy code in stable**
- The multiplication was introduced in commit a578f2a58c3ab, merged in
  v6.18
- The cherry-pick f6c0f3d24478a0 has `Cc: stable@vger.kernel.org`, so it
  was intended for backport to active stable trees
- The 7.0 tree we're evaluating definitely has this code
- Any stable tree that received the multi-xcc fix backport also has the
  bug

**Step 6.2: Backport complexity** - The patch should apply cleanly since
the code structure hasn't changed significantly.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:** drm/amdgpu (KFD) - GPU compute driver. Used by ROCm.
Criticality: IMPORTANT for AMD GPU users.

**Step 7.2:** Very actively developed subsystem.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affects users of AMD multi-XCC GPUs (MI200/MI300 series)
who use CRIU checkpoint/restore.

**Step 8.2: Trigger conditions**
- Requires multi-XCC AMD GPU hardware
- Requires CRIU checkpoint operation
- Requires `cp_hqd_cntl_stack_size` large enough to overflow when
  multiplied by XCC count
- Triggerable from userspace via KFD ioctl

**Step 8.3: Failure mode** - Out-of-bounds kernel heap write. Severity:
**HIGH** (memory corruption, potential crash, potential security
vulnerability).

**Step 8.4: Risk-Benefit**
- Benefit: Prevents kernel heap buffer overflow -> HIGH
- Risk: Very low - adds a standard overflow check, graceful error return
- Ratio: Strongly favorable for backport

## PHASE 9: SYNTHESIS

**Evidence FOR backporting:**
- Fixes a real buffer overflow (out-of-bounds heap write)
- Small and contained (+22/-8 lines, mostly plumbing)
- Uses standard kernel overflow checking macro (`check_mul_overflow`)
- Obviously correct - reviewed by subsystem maintainer Alex Deucher
- The buggy code was itself marked `Cc: stable` (the multi-xcc fix), so
  the bug exists in stable trees
- Graceful error handling (returns -EINVAL instead of corrupting memory)

**Evidence AGAINST backporting:**
- The bug requires specific hardware (multi-XCC AMD GPUs) and specific
  operation (CRIU checkpoint)
- The overflow may require unrealistic `cp_hqd_cntl_stack_size` values
  in practice
- The function signature change touches 6 files (though all changes are
  mechanical)

**Stable rules checklist:**
1. Obviously correct and tested? **YES** - uses standard
   `check_mul_overflow()`, reviewed by maintainer
2. Fixes a real bug? **YES** - buffer overflow from integer overflow
3. Important issue? **YES** - out-of-bounds heap write, potential memory
   corruption
4. Small and contained? **YES** - 30 lines total, core logic is 3 lines
5. No new features? **YES** - purely defensive overflow check
6. Applies to stable? **YES** - any tree with the multi-xcc checkpoint
   fix (6.18+, plus stable backports)

## Verification

- [Phase 1] Parsed subject: drm/amdgpu, "Check" (adding safety check),
  overflow in checkpoint stack size
- [Phase 1] Tags: Reviewed-by Alex Deucher (subsystem maintainer),
  Signed-off-by Alex Deucher
- [Phase 2] Diff: 6 files, +22/-8 lines. Core fix is
  `check_mul_overflow()` in `get_checkpoint_info()` v9
- [Phase 2] Traced overflow to buffer allocation in
  `criu_checkpoint_queues_device()` (line 895: kzalloc) and memcpy in
  `checkpoint_mqd()` (line 412) / `checkpoint_mqd_v9_4_3()` (lines
  424-430)
- [Phase 3] git blame: multiplication introduced by f6c0f3d24478a0
  (2025-07-16), cherry-pick of a578f2a58c3ab with `Cc: stable`
- [Phase 3] Original `get_checkpoint_info` introduced by 3a9822d7bd623b
  (2021-01-25)
- [Phase 3] Multi-xcc fix entered mainline in v6.18
- [Phase 4] Found original patch at spinics.net/lists/amd-
  gfx/msg138647.html, Alex Deucher reviewed at msg138731
- [Phase 4] No NAKs, no concerns raised
- [Phase 5] Traced call chain: KFD ioctl -> kfd_process_get_queue_info
  -> get_queue_data_sizes -> pqm_get_queue_checkpoint_info ->
  get_queue_checkpoint_info -> get_checkpoint_info
- [Phase 5] Confirmed overflowed value feeds into buffer allocation
  (kzalloc) but actual memcpy uses non-overflowed per-XCC size
- [Phase 6] Buggy code exists in mainline since v6.18 and in any stable
  tree that backported the multi-xcc checkpoint fix
- [Phase 8] Failure mode: heap buffer overflow (out-of-bounds write),
  severity HIGH

**YES**

 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  | 7 +++++--
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  | 2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.h           | 3 ++-
 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c        | 7 +++++--
 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c        | 3 ++-
 drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 8 +++++++-
 6 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 3ddf06c755b52..ab3b2e7be9bd0 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -2720,7 +2720,7 @@ static int get_wave_state(struct device_queue_manager *dqm,
 			ctl_stack, ctl_stack_used_size, save_area_used_size);
 }
 
-static void get_queue_checkpoint_info(struct device_queue_manager *dqm,
+static int get_queue_checkpoint_info(struct device_queue_manager *dqm,
 			const struct queue *q,
 			u32 *mqd_size,
 			u32 *ctl_stack_size)
@@ -2728,6 +2728,7 @@ static void get_queue_checkpoint_info(struct device_queue_manager *dqm,
 	struct mqd_manager *mqd_mgr;
 	enum KFD_MQD_TYPE mqd_type =
 			get_mqd_type_from_queue_type(q->properties.type);
+	int ret = 0;
 
 	dqm_lock(dqm);
 	mqd_mgr = dqm->mqd_mgrs[mqd_type];
@@ -2735,9 +2736,11 @@ static void get_queue_checkpoint_info(struct device_queue_manager *dqm,
 	*ctl_stack_size = 0;
 
 	if (q->properties.type == KFD_QUEUE_TYPE_COMPUTE && mqd_mgr->get_checkpoint_info)
-		mqd_mgr->get_checkpoint_info(mqd_mgr, q->mqd, ctl_stack_size);
+		ret = mqd_mgr->get_checkpoint_info(mqd_mgr, q->mqd, ctl_stack_size);
 
 	dqm_unlock(dqm);
+
+	return ret;
 }
 
 static int checkpoint_mqd(struct device_queue_manager *dqm,
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
index ef07e44916f80..3272328da11f9 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
@@ -192,7 +192,7 @@ struct device_queue_manager_ops {
 
 	int (*reset_queues)(struct device_queue_manager *dqm,
 					uint16_t pasid);
-	void	(*get_queue_checkpoint_info)(struct device_queue_manager *dqm,
+	int	(*get_queue_checkpoint_info)(struct device_queue_manager *dqm,
 				  const struct queue *q, u32 *mqd_size,
 				  u32 *ctl_stack_size);
 
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.h b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.h
index 2429d278ef0eb..06ca6235ff1b7 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.h
@@ -102,7 +102,8 @@ struct mqd_manager {
 				  u32 *ctl_stack_used_size,
 				  u32 *save_area_used_size);
 
-	void	(*get_checkpoint_info)(struct mqd_manager *mm, void *mqd, uint32_t *ctl_stack_size);
+	int	(*get_checkpoint_info)(struct mqd_manager *mm, void *mqd,
+				       uint32_t *ctl_stack_size);
 
 	void	(*checkpoint_mqd)(struct mqd_manager *mm,
 				  void *mqd,
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c
index a535f151cb5fd..fe471a8b98095 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c
@@ -393,11 +393,14 @@ static int get_wave_state(struct mqd_manager *mm, void *mqd,
 	return 0;
 }
 
-static void get_checkpoint_info(struct mqd_manager *mm, void *mqd, u32 *ctl_stack_size)
+static int get_checkpoint_info(struct mqd_manager *mm, void *mqd, u32 *ctl_stack_size)
 {
 	struct v9_mqd *m = get_mqd(mqd);
 
-	*ctl_stack_size = m->cp_hqd_cntl_stack_size * NUM_XCC(mm->dev->xcc_mask);
+	if (check_mul_overflow(m->cp_hqd_cntl_stack_size, NUM_XCC(mm->dev->xcc_mask), ctl_stack_size))
+		return -EINVAL;
+
+	return 0;
 }
 
 static void checkpoint_mqd(struct mqd_manager *mm, void *mqd, void *mqd_dst, void *ctl_stack_dst)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c
index 69c1b8a690b86..5a758ed14ea50 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c
@@ -275,10 +275,11 @@ static int get_wave_state(struct mqd_manager *mm, void *mqd,
 	return 0;
 }
 
-static void get_checkpoint_info(struct mqd_manager *mm, void *mqd, u32 *ctl_stack_size)
+static int get_checkpoint_info(struct mqd_manager *mm, void *mqd, u32 *ctl_stack_size)
 {
 	/* Control stack is stored in user mode */
 	*ctl_stack_size = 0;
+	return 0;
 }
 
 static void checkpoint_mqd(struct mqd_manager *mm, void *mqd, void *mqd_dst, void *ctl_stack_dst)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
index f5d2847e1cbb4..cc2621ae12f9c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
@@ -1070,6 +1070,7 @@ int pqm_get_queue_checkpoint_info(struct process_queue_manager *pqm,
 				  uint32_t *ctl_stack_size)
 {
 	struct process_queue_node *pqn;
+	int ret;
 
 	pqn = get_queue_by_qid(pqm, qid);
 	if (!pqn) {
@@ -1082,9 +1083,14 @@ int pqm_get_queue_checkpoint_info(struct process_queue_manager *pqm,
 		return -EOPNOTSUPP;
 	}
 
-	pqn->q->device->dqm->ops.get_queue_checkpoint_info(pqn->q->device->dqm,
+	ret = pqn->q->device->dqm->ops.get_queue_checkpoint_info(pqn->q->device->dqm,
 						       pqn->q, mqd_size,
 						       ctl_stack_size);
+	if (ret) {
+		pr_debug("amdkfd: Overflow while computing stack size for queue %d\n", qid);
+		return ret;
+	}
+
 	return 0;
 }
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.19] drm/amd/display: Clamp dc_cursor_position x_hotspot to prevent integer overflow

[Sasha Levin]

From: Benjamin Nwankwo <Benjamin.Nwankwo@amd.com>

[ Upstream commit a2aa7987de1169548c465f6cc1019d2112e0e8b5 ]

why:
Workaround for duplicate cursor. Cursor offsetting via x_hotspot attempts
to write a 32 bit unsigned integer to the 8 bit field CURSOR_HOT_SPOT_X.
This wraps cursor position back into focus if x_hotspot exceeds 8 bits,
making duplicate cursors visible

how:
Clamp x_hotspot before writing to hardware

Reviewed-by: Charlene Liu <charlene.liu@amd.com>
Reviewed-by: Nevenko Stupar <nevenko.stupar@amd.com>
Signed-off-by: Benjamin Nwankwo <Benjamin.Nwankwo@amd.com>
Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a comprehensive understanding of the bug. Let me compile the
full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `drm/amd/display` (AMD display driver, DCN401 specifically)
- Action verb: "Clamp" (prevent overflow, clearly a bug fix)
- Summary: Clamp x_hotspot value before writing to 8-bit hardware
  register to prevent integer overflow causing duplicate cursors

**Step 1.2: Tags**
- `Reviewed-by: Charlene Liu` and `Reviewed-by: Nevenko Stupar` - two
  AMD engineers reviewed
- `Signed-off-by: Benjamin Nwankwo` (author), `Signed-off-by: Chuanyu
  Tseng` (submitter)
- `Tested-by: Dan Wheeler` - standard AMD display QA tester
- `Signed-off-by: Alex Deucher` - AMD GPU subsystem maintainer accepted
  the patch
- No Fixes: tag (expected for candidate review)
- No Cc: stable tag (expected)

**Step 1.3: Commit Body**
- Bug: 32-bit `x_hotspot` value written to 8-bit `CURSOR_HOT_SPOT_X`
  hardware register
- Symptom: Value wraps, causing cursor position to jump back, creating
  visible duplicate cursors
- Fix: Clamp `x_hotspot` to 0xFF before hardware register write

**Step 1.4: Hidden Bug Fix Detection**
This is explicitly a bug fix (visual display glitch with duplicate
cursors). Not hidden.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed:
  `drivers/gpu/drm/amd/display/dc/hubp/dcn401/dcn401_hubp.c`
- +4 lines, -3 lines (net +1)
- Function modified: `hubp401_cursor_set_position()`
- Scope: Single-file surgical fix

**Step 2.2: Code Flow Change**
1. New variable `x_hotspot_clamped = pos->x_hotspot` declared
2. Before writing to HW register, clamp: `if (x_hotspot_clamped > 0xFF)
   x_hotspot_clamped = 0xFF;`
3. Use `x_hotspot_clamped` instead of `pos->x_hotspot` in
   `REG_SET_2(CURSOR_HOT_SPOT, ...)` call

**Step 2.3: Bug Mechanism**
Category: Integer overflow / type mismatch bug. A 32-bit value is
truncated to 8 bits by hardware, causing wraparound. The fix clamps the
value to 8-bit range before writing.

**Step 2.4: Fix Quality**
Obviously correct - the hardware register is 8 bits, so values > 255 are
meaningless. Clamping to 0xFF is the right approach. Zero regression
risk - the clamped path already results in incorrect cursor positioning,
so saturating at max is strictly better than wrapping.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
The buggy line (`CURSOR_HOT_SPOT_X, pos->x_hotspot`) was last touched by
commit `518a368c57a0e6` ("Update cursor offload assignments", by Alvin
Lee, 2025-10-02). The underlying bug pattern has existed since the
function was first introduced in commit `ee8287e068a3` ("Fix cursor
issues with ODMs and HW rotations"), first appearing in v6.11.

**Step 3.2: No Fixes: tag** (expected)

**Step 3.3: File History**
17 commits between v6.11 and v7.0 modified this file. The function has
been actively developed. The v7.0 version includes cursor offload
support that doesn't exist in v6.11/v6.12.

**Step 3.4: Author**
Benjamin Nwankwo is an AMD display engineer. The patch was submitted
through Chuanyu Tseng as part of a DC patch series.

**Step 3.5: Dependencies**
The fix is self-contained. No dependencies on other patches. The core
logic (clamp before REG_SET_2) applies regardless of the cursor offload
changes.

## PHASE 4: MAILING LIST RESEARCH

The patch was submitted as [PATCH v2 8/9] in "DC Patches March 10, 2026"
series. It's v2 (revised from v1 - v1 reference:
https://patchwork.freedesktop.org/patch/710768/). The series also
includes other unrelated DC patches. No objections or NAKs found on the
mailing list. No explicit stable nomination by reviewers.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Key Function**: `hubp401_cursor_set_position()`

**Step 5.2: Callers**
Called via `hubp->funcs->set_cursor_position()` from
`dcn401_set_cursor_position()` in the hwseq layer. This is the main
cursor position programming path for DCN401 hardware.

**Step 5.4: Critical Call Chain - THE ACTUAL TRIGGER PATH**
In `dcn401_set_cursor_position()` (lines 1177-1182 and 1196-1202):

```1177:1202:drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c
        if (x_pos < 0) {
                pos_cpy.x_hotspot -= x_pos;
                // ...
                x_pos = 0;
        }
        // ...
        if (bottom_pipe_x_pos < 0) {
                // ...
                pos_cpy.x_hotspot -= bottom_pipe_x_pos;
```

When ODM combining or MPC combining is active and the cursor crosses
slice boundaries, `x_pos` becomes negative. The line `pos_cpy.x_hotspot
-= x_pos` (where `x_pos` is negative) **adds** a potentially large value
to `x_hotspot`. For example, if the cursor is 500 pixels to the left of
an ODM slice boundary, `x_hotspot` grows by 500 -- far exceeding the
8-bit register maximum of 255.

This confirms the bug is **real and triggerable** in ODM/MPC combining
scenarios (multi-monitor, high-resolution displays).

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable**
The file exists from v6.11 onwards. The ODM hotspot inflation code
(`x_hotspot -= x_pos`) exists in both v6.11 and v6.12. The bug is
present in all versions containing DCN401.

**Step 6.2: Backport Complications**
The v6.11/v6.12 versions of `hubp401_cursor_set_position()` differ from
v7.0 (no cursor offload path, different variable naming). The patch
would need minor rework for older trees but the clamping concept applies
cleanly.

## PHASE 7: SUBSYSTEM CONTEXT

- Subsystem: `drivers/gpu/drm/amd/display` - AMD display driver
- Criticality: IMPORTANT (AMD GPUs are widely used; display bugs affect
  all users of that hardware)
- DCN401 = AMD RDNA4 display controller

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**: Users with AMD DCN401 (RDNA4) GPUs using
ODM combining or MPC combining (multi-monitor, high-resolution displays)

**Step 8.2: Trigger Conditions**: Cursor moves across ODM or MPC slice
boundaries with enough offset to push x_hotspot > 255. Common in multi-
monitor or ultra-wide setups.

**Step 8.3: Failure Mode**: Visible duplicate cursor artifact. Severity:
MEDIUM (user-visible display glitch, not a crash/security/corruption
issue, but very annoying)

**Step 8.4: Risk-Benefit**:
- BENEFIT: High - fixes a visible display bug for AMD GPU users
- RISK: Very Low - 3 lines, obviously correct clamping, zero regression
  potential

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Fixes a real, user-visible display bug (duplicate cursors)
- Trigger path confirmed: ODM/MPC combining inflates x_hotspot beyond
  8-bit register width
- Fix is minimal (3 effective lines), obviously correct, zero regression
  risk
- Reviewed by 2 AMD engineers, tested, accepted by subsystem maintainer
- Hardware workaround pattern - exactly the type of fix allowed in
  stable
- Bug exists in all stable trees containing DCN401 (v6.11+)

**Evidence AGAINST backporting:**
- Not a crash, security issue, or data corruption
- DCN401 is relatively new hardware (v6.11+)
- Would need minor rework for v6.11/v6.12 due to different function
  structure
- No explicit stable nomination or Fixes: tag

**Stable Rules Checklist:**
1. Obviously correct and tested? YES (trivial clamp, Tested-by)
2. Fixes a real bug? YES (duplicate cursor visible to users)
3. Important issue? MEDIUM (visible display glitch, not crash/security)
4. Small and contained? YES (3 lines, single function)
5. No new features/APIs? YES (pure bug fix)
6. Can apply to stable? YES for 7.0.y; needs minor rework for
   6.11.y/6.12.y

## Verification

- [Phase 1] Parsed tags: 2x Reviewed-by (AMD engineers), Tested-by (Dan
  Wheeler), Signed-off by Alex Deucher (subsystem maintainer)
- [Phase 2] Diff analysis: 3 effective lines in
  `hubp401_cursor_set_position()`, clamps x_hotspot to 0xFF before
  register write
- [Phase 3] git blame: buggy line from commit 518a368c57a0e6 (cursor
  offload update); original function from ee8287e068a3 (v6.11)
- [Phase 3] git ls-tree: confirmed dcn401_hubp.c exists in v6.11, v6.12,
  v6.13, v7.0
- [Phase 4] Found patch at https://lists.freedesktop.org/archives/amd-
  gfx/2026-March/140330.html - part of v2 DC patch series
- [Phase 4] Cover letter at https://lists.freedesktop.org/archives/amd-
  gfx/2026-March/140322.html - no NAKs or concerns
- [Phase 5] Traced caller chain: `dcn401_set_cursor_position()` ->
  `hubp401_cursor_set_position()`. Confirmed at lines 1177-1182 and
  1196-1202 that `pos_cpy.x_hotspot -= x_pos` (with negative x_pos)
  inflates x_hotspot beyond 255 in ODM/MPC combining scenarios
- [Phase 5] Verified x_hotspot inflation code exists in v6.11 and v6.12
  versions of dcn401_hwseq.c
- [Phase 6] DCN401 max_cursor_size=64, but x_hotspot is inflated *after*
  initial position setup in hwseq layer, so 64-pixel limit doesn't
  prevent the overflow
- [Phase 6] Function structure differs between v6.12 and v7.0 (cursor
  offload); backport needs minor adaptation for older trees
- [Phase 8] Failure mode: duplicate cursor visible on screen (MEDIUM
  severity, user-visible display bug)

The fix is a small, safe hardware workaround that fixes a real visual
bug triggered by ODM/MPC combining on AMD DCN401 hardware. It meets
stable criteria as a hardware workaround with minimal risk and clear
benefit.

**YES**

 drivers/gpu/drm/amd/display/dc/hubp/dcn401/dcn401_hubp.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/hubp/dcn401/dcn401_hubp.c b/drivers/gpu/drm/amd/display/dc/hubp/dcn401/dcn401_hubp.c
index c205500290ecd..806b9bd9a3fcf 100644
--- a/drivers/gpu/drm/amd/display/dc/hubp/dcn401/dcn401_hubp.c
+++ b/drivers/gpu/drm/amd/display/dc/hubp/dcn401/dcn401_hubp.c
@@ -739,9 +739,8 @@ void hubp401_cursor_set_position(
 	int x_pos_viewport = 0;
 	int x_hot_viewport = 0;
 	uint32_t cur_en = pos->enable ? 1 : 0;
-
+	uint32_t x_hotspot_clamped = pos->x_hotspot;
 	hubp->curs_pos = *pos;
-
 	/* Recout is zero for pipes if the entire dst_rect is contained
 	 * within preceeding ODM slices.
 	 */
@@ -772,6 +771,8 @@ void hubp401_cursor_set_position(
 
 	ASSERT(param->h_scale_ratio.value);
 
+	if (x_hotspot_clamped > 0xFF)
+		x_hotspot_clamped = 0xFF;
 	if (param->h_scale_ratio.value)
 		dst_x_offset = dc_fixpt_floor(dc_fixpt_div(
 			dc_fixpt_from_int(dst_x_offset),
@@ -792,7 +793,7 @@ void hubp401_cursor_set_position(
 			CURSOR_Y_POSITION, pos->y);
 
 		REG_SET_2(CURSOR_HOT_SPOT, 0,
-			CURSOR_HOT_SPOT_X, pos->x_hotspot,
+			CURSOR_HOT_SPOT_X, x_hotspot_clamped,
 			CURSOR_HOT_SPOT_Y, pos->y_hotspot);
 
 		REG_SET(CURSOR_DST_OFFSET, 0,
-- 
2.53.0

[PATCH AUTOSEL 7.0] drm/amdgpu/userq: defer queue publication until create completes

[Sasha Levin]

From: Sunil Khatri <sunil.khatri@amd.com>

[ Upstream commit 28cacaace5cde8318b7da967b3955a73cc6de91a ]

The userq create path publishes queues to global xarrays such as
userq_doorbell_xa and userq_xa before creation was fully complete.
Later on if create queue fails, teardown could free an already
visible queue, opening a UAF race with concurrent queue walkers.
Also calling amdgpu_userq_put in such cases complicates the cleanup.

Solution is to defer queue publication until create succeeds and no
partially initialized queue is exposed.

Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
Record: [drm/amdgpu/userq] [defer] — Defers queue publication to global
xarrays until `amdgpu_userq_create()` completes, preventing UAF races
with concurrent queue walkers.

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by**: Sunil Khatri (author, regular AMD GPU contributor)
- **Reviewed-by**: Christian König (AMD GPU subsystem maintainer —
  strong quality signal)
- **Signed-off-by**: Alex Deucher (AMD GPU maintainer, committer)
- No Fixes: tag, no Cc: stable, no Reported-by. Absence of
  Fixes/Cc:stable is expected for candidates under review.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The body clearly describes:
- **Bug**: The userq create path publishes queues to `userq_doorbell_xa`
  and `userq_xa` before creation is fully complete.
- **Failure mode**: If create fails later, teardown frees a queue that's
  already visible, opening a UAF race with concurrent queue walkers
  (suspend/resume, reset, enforce isolation).
- **Root cause**: Premature publication of partially initialized objects
  to global data structures.

### Step 1.4: DETECT HIDDEN BUG FIXES
This is explicitly a UAF race fix, not disguised. The commit also
implicitly fixes resource leaks on error paths (the old `kasprintf`
failure leaked xarray entries).

---

## PHASE 2: DIFF ANALYSIS — LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
- **File**: `drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c` (+33/−33 lines)
- **Function**: `amdgpu_userq_create()`
- **Scope**: Single function in a single file — surgical.

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**BEFORE** (current stable tree code):
1. `mqd_create()` → `kref_init()` → `xa_store_irq(doorbell_xa)` →
   `xa_alloc(userq_xa)` → `map_helper()` → `kasprintf()` → debugfs

**AFTER** (with this patch):
1. `mqd_create()` → `map_helper()` → `kref_init()` →
   `xa_alloc(userq_xa)` → `xa_store_irq(doorbell_xa)` → debugfs

The key reordering: queue creation and mapping are fully completed
BEFORE the queue is published to global xarrays. Only on success are the
xarray entries created.

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Category**: UAF race condition + resource leaks on error paths.

Specific bugs in the current stable tree code:

1. **UAF race**: Between `xa_store_irq(doorbell_xa)` (line 863) and
   `map_helper()` (line 891), the queue is visible to concurrent walkers
   via `xa_for_each(&adev->userq_doorbell_xa)`. I verified 7 call sites
   iterate this xarray (suspend, resume, enforce isolation stop/start,
   pre/post reset, mes detection). If create fails at `map_helper()`,
   the error path frees the queue while walkers may hold a pointer to
   it.

2. **Missing doorbell xa cleanup**: The `xa_alloc` failure path (line
   872-880) does NOT call `xa_erase_irq(&adev->userq_doorbell_xa,
   index)`, leaking the doorbell xarray entry pointing to freed memory.

3. **kasprintf leak**: The `kasprintf` failure (line 902-906) does `goto
   unlock` without cleaning up xarray entries, the mapped queue, or any
   other resources — the queue is abandoned in global xarrays.

### Step 2.4: ASSESS THE FIX QUALITY
- The fix is obviously correct: it simply reorders operations so
  publication happens last.
- Error paths in the new code properly clean up everything (including
  calling `amdgpu_userq_unmap_helper` if needed).
- The `kasprintf` allocation is replaced with a stack buffer (`char
  queue_name[32]` + `scnprintf`), eliminating that failure path
  entirely.
- Regression risk is low — the fix only changes ordering within the
  create path.
- Reviewed by Christian König (subsystem maintainer).

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
- The xarray-based queue management was introduced by `f18719ef4bb7b`
  (Jesse.Zhang, 2025-10-21) — "Convert amdgpu userqueue management from
  IDR to XArray"
- The refcount mechanism was added by `65b5c326ce410` (Sunil Khatri,
  2026-03-02) — already cherry-picked to this stable tree with `Cc:
  <stable@vger.kernel.org>`

### Step 3.2: FOLLOW THE FIXES: TAG
No Fixes: tag present (expected for review candidates).

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Between the mainline refcount commit (`4952189b284d4`) and this commit
(`28cacaace5cde`), there are 3 intermediate commits:
- `2d60e9898a1d4` — change queue id type to u32 (NOT in stable tree)
- `f0e46fd06c3f7` — add missing `xa_erase_irq` in xa_alloc failure (NOT
  in stable tree)
- `a978ed3d6454e` — add missing `xa_erase_irq` in map_helper failure
  (NOT in stable tree)

**This commit supersedes both `f0e46fd06c3f7` and `a978ed3d6454e`** by
restructuring the code to eliminate these error paths entirely.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Sunil Khatri is an active AMD GPU contributor with multiple commits in
the subsystem. He authored the refcount commit which was already
selected for stable.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
**Critical finding**: The diff expects context lines that include
`xa_erase_irq(&adev->userq_doorbell_xa, index)` in the xa_alloc and
map_helper failure paths. These lines were added by intermediate commits
`f0e46fd06c3f7` and `a978ed3d6454e`, which are **NOT in the stable
tree**. The patch will **not apply cleanly** without either including
those intermediate commits or manually adjusting the diff.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
- `b4 dig -c 28cacaace5cde` found nothing (patch may have gone through a
  different path).
- Web search found the patch series on the amd-gfx mailing list as
  `[PATCH v4 1/3]`.
- Fetched the review thread at
  `https://lists.freedesktop.org/archives/amd-
  gfx/2026-March/140034.html`.
- Christian König reviewed and gave `Reviewed-by` on patch 1/3 (this
  commit).

### Step 4.2: CHECK WHO REVIEWED THE PATCH
- Christian König (subsystem maintainer) reviewed and approved.
- Alex Deucher (AMD GPU maintainer) committed it.

### Step 4.3: SEARCH FOR THE BUG REPORT
No external bug report. The author identified the race condition through
code inspection while working on the refcount series.

### Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
The patch is part of a v4 3-patch series:
- 1/3: This commit (defer queue publication) — **bug fix**
- 2/3: "declutter the code with goto" — cleanup, not needed for stable
- 3/3: "push userq debugfs function in amdgpu_debugfs files" —
  refactoring, not needed for stable

Only patch 1/3 is a bug fix.

### Step 4.5: CHECK STABLE MAILING LIST HISTORY
The predecessor commit (refcount userqueues, `65b5c326ce410`) was
explicitly marked `Cc: <stable@vger.kernel.org>`, confirming the stable
maintainers already identified the userq race conditions as stable-
worthy. This commit is a direct follow-up fix to the same issue.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.4: TRACE CALLERS AND IMPACT SURFACE
- `amdgpu_userq_create()` is called from `amdgpu_userq_ioctl()` →
  reachable from userspace via DRM IOCTL.
- The concurrent walkers iterating `userq_doorbell_xa` include:
  - `amdgpu_userq_suspend()` / `amdgpu_userq_resume()` — power
    management
  - `amdgpu_userq_stop_sched_for_enforce_isolation()` /
    `amdgpu_userq_start_sched_for_enforce_isolation()` — workload
    isolation
  - `amdgpu_userq_pre_reset()` / `amdgpu_userq_post_reset()` — GPU reset
  - `mes_userqueue.c:` detect-and-reset path

These are all real, frequently exercised code paths (suspend/resume, GPU
reset).

### Step 5.5: SIMILAR PATTERNS
The doorbell xa walkers do NOT use `amdgpu_userq_get()` (the kref-
protected accessor). They iterate with `xa_for_each` and use the queue
pointer directly, meaning the kref doesn't protect against the UAF in
these paths.

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
Yes. The userq code exists in this 7.0 stable tree. The buggy ordering
was introduced with the xarray conversion (`f18719ef4bb7b`, 2025-10-21),
which is in this tree.

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
**The patch will NOT apply cleanly.** The intermediate commits
`f0e46fd06c3f7` and `a978ed3d6454e` added `xa_erase_irq` lines that the
diff expects to see in the context. These are missing from the current
stable tree. The diff would need manual adjustment or the intermediate
commits need to be included first.

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE
The refcount commit (`65b5c326ce410`) is in this tree, but the
intermediate xa_erase fixes and this commit are not.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
- **Subsystem**: drivers/gpu/drm/amd/amdgpu — IMPORTANT (widely used AMD
  GPU driver)
- User queues are a newer feature but actively used on modern AMD
  hardware.

### Step 7.2: SUBSYSTEM ACTIVITY
Very active — many commits per week in amdgpu. The userq subsystem is
under active development.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
Users of AMD GPUs with userqueue support (GFX11+, GFX12+, SDMA v6/v7).
This includes modern Radeon RX 7000/8000 series and data center GPUs.

### Step 8.2: TRIGGER CONDITIONS
- **Trigger**: Create a userqueue via IOCTL while a concurrent operation
  (suspend/resume, GPU reset, enforce isolation) is walking the doorbell
  xarray.
- **Likelihood**: Medium — requires timing overlap between queue
  creation failure and concurrent walker.
- **Unprivileged trigger**: Yes — the IOCTL is accessible to
  unprivileged users (no CAP check for normal priority).

### Step 8.3: FAILURE MODE SEVERITY
- **UAF**: When triggered, can cause kernel crash (oops), memory
  corruption, or potentially privilege escalation.
- **Severity**: HIGH — UAF reachable from unprivileged userspace.

### Step 8.4: RISK-BENEFIT RATIO
- **Benefit**: HIGH — prevents UAF, fixes resource leaks, hardens
  security.
- **Risk**: LOW-MEDIUM — 66 lines changed, single function, but needs
  backport adjustment.
- **Ratio**: Strongly favors backporting.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Fixes a real UAF race condition reachable from unprivileged userspace
- Fixes resource leaks on error paths (kasprintf failure, missing
  xa_erase)
- Reviewed and approved by Christian König (subsystem maintainer) and
  Alex Deucher (committer)
- Single file, single function change — well-contained
- The prerequisite refcount commit is already in stable (with Cc: stable
  tag)
- Supersedes two intermediate fixes that are also needed for stable

**AGAINST backporting:**
- The diff does NOT apply cleanly (context mismatch due to missing
  intermediate commits)
- Part of a 3-patch series (but only 1/3 is needed)
- Moderate size (66 lines)

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** — reviewed by subsystem
   maintainer, reordering is straightforward
2. Fixes a real bug? **YES** — UAF race with concurrent queue walkers
3. Important issue? **YES** — UAF reachable from userspace = security
   concern
4. Small and contained? **YES** — single function in single file
5. No new features or APIs? **YES** — pure bug fix
6. Can apply to stable? **NEEDS ADJUSTMENT** — intermediate commits
   missing from tree

### Step 9.3: EXCEPTION CATEGORIES
Not an exception category — standard bug fix.

### Step 9.4: DECISION
The commit fixes a real UAF race condition in the AMD GPU userqueue
create path. The race is between queue creation (IOCTL) and concurrent
doorbell xarray walkers (suspend/resume, GPU reset, enforce isolation).
The fix is well-contained, well-reviewed, and the prerequisite refcount
infrastructure is already in this stable tree. The backport will need
manual adjustment due to missing intermediate context, but the
underlying bugs are real and security-relevant.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Christian König, Signed-off-by Alex
  Deucher (both AMD GPU maintainers)
- [Phase 2] Diff analysis: 33 lines added, 33 removed in
  `amdgpu_userq_create()`, reorders xa_store/xa_alloc after map_helper
- [Phase 2] Verified current tree at lines 858-906: queue published to
  doorbell_xa at line 863, BEFORE map_helper at line 891
- [Phase 2] Verified kasprintf failure at line 902-906 leaks xarray
  entries (goto unlock without cleanup)
- [Phase 2] Verified xa_alloc failure at line 872-880 does NOT call
  xa_erase_irq for doorbell_xa
- [Phase 3] git blame: xarray code from f18719ef4bb7b (2025-10-21),
  refcount from 65b5c326ce410 (in stable, Cc: stable)
- [Phase 3] Intermediate commits f0e46fd06c3f7 and a978ed3d6454e NOT in
  stable tree (verified with git log --grep)
- [Phase 3] git show 28cacaace5cde: confirmed mainline commit exists,
  authored 2026-03-04
- [Phase 4] Mailing list review at freedesktop.org: Christian König gave
  Reviewed-by on patch 1/3
- [Phase 4] Series is v4 1/3; patches 2/3 and 3/3 are
  cleanup/refactoring (not needed for stable)
- [Phase 5] Verified 7 call sites using
  xa_for_each(&adev->userq_doorbell_xa) — all are real paths (suspend,
  resume, reset, enforce isolation)
- [Phase 5] Verified doorbell xa walkers do NOT use amdgpu_userq_get()
  (no kref protection)
- [Phase 6] Verified patch does NOT apply cleanly: diff expects
  xa_erase_irq lines not in stable tree
- [Phase 6] Refcount prerequisite (65b5c326ce410) confirmed in stable
  tree
- [Phase 7] amdgpu is an actively maintained, widely used driver
  subsystem
- [Phase 8] IOCTL is accessible to unprivileged users (no CAP check for
  normal priority)
- UNVERIFIED: Cannot determine exact AMD GPU models that exercise this
  code path in practice (depends on firmware/hardware support for
  userqueues)

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 66 +++++++++++------------
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
index 1849894d2837b..09f1d05328897 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
@@ -765,7 +765,6 @@ amdgpu_userq_create(struct drm_file *filp, union drm_amdgpu_userq *args)
 	const struct amdgpu_userq_funcs *uq_funcs;
 	struct amdgpu_usermode_queue *queue;
 	struct amdgpu_db_info db_info;
-	char *queue_name;
 	bool skip_map_queue;
 	u32 qid;
 	uint64_t index;
@@ -855,32 +854,6 @@ amdgpu_userq_create(struct drm_file *filp, union drm_amdgpu_userq *args)
 		goto unlock;
 	}
 
-	/* drop this refcount during queue destroy */
-	kref_init(&queue->refcount);
-
-	/* Wait for mode-1 reset to complete */
-	down_read(&adev->reset_domain->sem);
-	r = xa_err(xa_store_irq(&adev->userq_doorbell_xa, index, queue, GFP_KERNEL));
-	if (r) {
-		kfree(queue);
-		up_read(&adev->reset_domain->sem);
-		goto unlock;
-	}
-
-	r = xa_alloc(&uq_mgr->userq_xa, &qid, queue,
-		     XA_LIMIT(1, AMDGPU_MAX_USERQ_COUNT), GFP_KERNEL);
-	if (r) {
-		drm_file_err(uq_mgr->file, "Failed to allocate a queue id\n");
-		amdgpu_userq_fence_driver_free(queue);
-		xa_erase_irq(&adev->userq_doorbell_xa, index);
-		uq_funcs->mqd_destroy(queue);
-		kfree(queue);
-		r = -ENOMEM;
-		up_read(&adev->reset_domain->sem);
-		goto unlock;
-	}
-	up_read(&adev->reset_domain->sem);
-
 	/* don't map the queue if scheduling is halted */
 	if (adev->userq_halt_for_enforce_isolation &&
 	    ((queue->queue_type == AMDGPU_HW_IP_GFX) ||
@@ -892,28 +865,55 @@ amdgpu_userq_create(struct drm_file *filp, union drm_amdgpu_userq *args)
 		r = amdgpu_userq_map_helper(queue);
 		if (r) {
 			drm_file_err(uq_mgr->file, "Failed to map Queue\n");
-			xa_erase_irq(&adev->userq_doorbell_xa, index);
-			xa_erase(&uq_mgr->userq_xa, qid);
-			amdgpu_userq_fence_driver_free(queue);
 			uq_funcs->mqd_destroy(queue);
+			amdgpu_userq_fence_driver_free(queue);
 			kfree(queue);
 			goto unlock;
 		}
 	}
 
-	queue_name = kasprintf(GFP_KERNEL, "queue-%d", qid);
-	if (!queue_name) {
+	/* drop this refcount during queue destroy */
+	kref_init(&queue->refcount);
+
+	/* Wait for mode-1 reset to complete */
+	down_read(&adev->reset_domain->sem);
+	r = xa_alloc(&uq_mgr->userq_xa, &qid, queue,
+		     XA_LIMIT(1, AMDGPU_MAX_USERQ_COUNT), GFP_KERNEL);
+	if (r) {
+		if (!skip_map_queue)
+			amdgpu_userq_unmap_helper(queue);
+
+		uq_funcs->mqd_destroy(queue);
+		amdgpu_userq_fence_driver_free(queue);
+		kfree(queue);
 		r = -ENOMEM;
+		up_read(&adev->reset_domain->sem);
 		goto unlock;
 	}
 
+	r = xa_err(xa_store_irq(&adev->userq_doorbell_xa, index, queue, GFP_KERNEL));
+	if (r) {
+		xa_erase(&uq_mgr->userq_xa, qid);
+		if (!skip_map_queue)
+			amdgpu_userq_unmap_helper(queue);
+
+		uq_funcs->mqd_destroy(queue);
+		amdgpu_userq_fence_driver_free(queue);
+		kfree(queue);
+		up_read(&adev->reset_domain->sem);
+		goto unlock;
+	}
+	up_read(&adev->reset_domain->sem);
+
 #if defined(CONFIG_DEBUG_FS)
+	char queue_name[32];
+
+	scnprintf(queue_name, sizeof(queue_name), "queue_%d", qid);
 	/* Queue dentry per client to hold MQD information   */
 	queue->debugfs_queue = debugfs_create_dir(queue_name, filp->debugfs_client);
 	debugfs_create_file("mqd_info", 0444, queue->debugfs_queue, queue, &amdgpu_mqd_info_fops);
 #endif
 	amdgpu_userq_init_hang_detect_work(queue);
-	kfree(queue_name);
 
 	args->out.queue_id = qid;
 	atomic_inc(&uq_mgr->userq_count[queue->queue_type]);
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] drm/amdgpu/userq: fix dma_fence refcount underflow in userq path

[Sasha Levin]

From: Sunil Khatri <sunil.khatri@amd.com>

[ Upstream commit 7a14a4e9b3fda05b907d0445a3be9e7c0e887f4e ]

An extra dma_fence_put() can drop the last reference to a fence while it is
still attached to a dma_resv object. This frees the fence prematurely via
dma_fence_release() while other users still hold the pointer.

Later accesses through dma_resv iteration may then operate on the freed
fence object, leading to refcount underflow warnings and potential hangs
when walking reservation fences.

Fix this by correcting the fence lifetime so the dma_resv object retains a
valid reference until it is done with the fence.i

[   31.133803] refcount_t: underflow; use-after-free.
[   31.133805] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x58/0x90, CPU#18: kworker/u96:1/188

Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
- **Subsystem**: drm/amdgpu/userq (AMD GPU user queue fence handling)
- **Action verb**: "fix" - explicitly states it's a bug fix
- **Summary**: Fixes dma_fence refcount underflow (double-put) in the
  userqueue wait ioctl path

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>** - Author, AMD
  employee, regular contributor to amdgpu
- **Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>** - Major
  DRM subsystem contributor
- **Reviewed-by: Christian König <christian.koenig@amd.com>** - AMD DRM
  maintainer, very strong endorsement
- **Signed-off-by: Alex Deucher <alexander.deucher@amd.com>** - amdgpu
  subsystem maintainer who committed it
- **No Fixes: tag** - expected for AUTOSEL candidates; the mailing list
  discussion confirmed it should be `Fixes: bea29bb0dd29
  ("drm/amdgpu/userq: Consolidate wait ioctl exit path")`
- **No explicit Cc: stable** - expected for AUTOSEL

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
- **Bug description**: An extra `dma_fence_put()` drops the last
  reference to a fence still attached to a `dma_resv` object, freeing it
  prematurely
- **Symptom**: refcount underflow warnings (`refcount_t: underflow; use-
  after-free`) followed by soft lockup (`watchdog: BUG: soft lockup -
  CPU#9 stuck for 26s!`)
- **Root cause**: After the "Consolidate wait ioctl exit path" commit
  merged both exit paths into one, fences get double-put: once inside
  the processing loop and once in the shared cleanup path
- **Stack traces**: Two crash traces provided - the refcount underflow
  in `drm_sched_entity_pop_job` and a 26s soft lockup in
  `dma_resv_iter_walk_unlocked` from `amdgpu_bo_kmap`

### Step 1.4: DETECT HIDDEN BUG FIXES
This is a clear, explicit bug fix, not a hidden one.

Record: This is a direct fix for a use-after-free / refcount underflow
caused by double `dma_fence_put()`.

---

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
- **Files changed**: 1
  (`drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c`)
- **Lines removed**: 5 (three `dma_fence_put(fences[i])` calls and
  associated braces)
- **Lines added**: 1 (reformatting `if (r)` to single line)
- **Net change**: -4 lines
- **Functions modified**: `amdgpu_userq_wait_ioctl()`
- **Scope**: Single-file, single-function surgical fix

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Hunk 1 (non-userq fence path)**: Removes `dma_fence_put(fences[i])` on
both the error and success branches of the `dma_fence_wait()` call for
non-userq fences.

**Hunk 2 (userq fence path)**: Removes `dma_fence_put(fences[i])` after
extracting fence_info for userq fences.

**Cleanup path** (unchanged): The `free_fences:` label at the end
already iterates through ALL fences and puts them:
```c
while (num_fences-- > 0)
    dma_fence_put(fences[num_fences]);
```

**Before**: Fences were put inside the loop (3 locations) AND again in
the cleanup loop = double-put.
**After**: Fences are only put in the cleanup loop = correct single put.

### Step 2.3: IDENTIFY THE BUG MECHANISM
- **Category**: Reference counting bug / double-free / use-after-free
- **Mechanism**: The `fences[]` array holds references obtained via
  `dma_fence_get()`. After the exit path consolidation (commit
  bea29bb0dd29), all exits go through `free_fences` which puts every
  fence. But the loop was also putting fences individually, resulting in
  each processed fence getting put twice. This drops the refcount below
  zero, triggering `refcount_warn_saturate()`, and may free the fence
  while `dma_resv` still holds the pointer, leading to use-after-free
  and hangs.

### Step 2.4: ASSESS THE FIX QUALITY
- **Obviously correct**: Yes. The cleanup loop handles all fence puts
  correctly. Removing the in-loop puts ensures exactly one put per get.
- **Minimal/surgical**: Yes, -4 net lines, only removing erroneous calls
- **Regression risk**: Extremely low - this purely removes double-puts.
  No new logic introduced.
- **Red flags**: None

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
- The in-loop `dma_fence_put` calls originated in commit
  `15e30a6e479282` (Arunpravin Paneer Selvam, 2024-10-30) - "Add wait
  IOCTL timeline syncobj support"
- The cleanup loop `free_fences` was modified by commit `048c1c4e51715`
  (Tvrtko Ursulin, 2026-02-23) - "Consolidate wait ioctl exit path",
  cherry-picked from mainline `bea29bb0dd29`
- The consolidation commit merged the success and error exit paths into
  one, creating the double-put

### Step 3.2: FOLLOW THE FIXES: TAG
The mailing list discussion confirms `Fixes: bea29bb0dd29
("drm/amdgpu/userq: Consolidate wait ioctl exit path")`. This commit is
present in the 7.0 stable tree as `048c1c4e51715`.

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Only one commit after the consolidation: `65b5c326ce410` (refcount
userqueues), which modifies different parts of the function (queue
lookup, not the fence loop). The fix is standalone.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Sunil Khatri is a regular AMD contributor with multiple commits to the
amdgpu userq subsystem. He authored the refcount userqueues commit and
multiple input validation fixes.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
This is patch 3/3 in a series, but it is self-contained. Patch 1/3 deals
with gem object lookup optimization and patch 2/3 with kvfree usage -
neither affects the same code or is needed for this fix.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Found at: https://lists.freedesktop.org/archives/amd-
gfx/2026-March/140504.html

**Tvrtko Ursulin** (the author of the commit that introduced the bug)
reviewed the fix, confirmed it's correct, and acknowledged he introduced
the bug:
> "I have to say the commit message confused me a bit, but the fix looks
correct. I say confused because isn't it a simple case of
amdgpu_userq_wait_ioctl() doing a potential double put? First one when
the dma_fence_wait() above fails or succeeds, and the second one in the
unwind loop. Which means it was me who broke it yet again."

He provided: `Fixes: bea29bb0dd29 ("drm/amdgpu/userq: Consolidate wait
ioctl exit path")` and added his `Reviewed-by`.

### Step 4.2: REVIEWER ANALYSIS
- **Tvrtko Ursulin** (Reviewed-by) - major DRM contributor and the
  author of the bug-introducing commit
- **Christian König** (Reviewed-by) - AMD DRM co-maintainer
- **Alex Deucher** (Signed-off-by) - amdgpu maintainer who applied the
  fix
- All key stakeholders reviewed and approved

### Step 4.3: BUG REPORT
The commit message includes a full kernel stack trace showing the actual
crash on real hardware (X570 AORUS ELITE with AMD GPU, running
6.19.0-amd-staging-drm-next). The bug was found through actual testing,
not just code review.

### Step 4.4/4.5: SERIES AND STABLE CONTEXT
The other patches in the series (1/3 and 2/3) are unrelated
optimizations. This patch is fully standalone.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.4: FUNCTION AND CALL CHAIN ANALYSIS
- **Modified function**: `amdgpu_userq_wait_ioctl()` - a DRM ioctl
  handler
- **Call chain**: `__se_sys_ioctl` -> `drm_ioctl` -> `amdgpu_drm_ioctl`
  -> `amdgpu_userq_wait_ioctl`
- **Reachability**: Directly reachable from userspace via ioctl syscall
  - any userspace GPU application using userqueues can trigger this
- **Impact**: The crash occurs in the GPU scheduler workqueue
  (`drm_sched_run_job_work`) when it encounters the freed fence, and
  causes a 26-second soft lockup

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
Yes. The buggy "Consolidate wait ioctl exit path" commit was cherry-
picked into the 7.0 stable tree as `048c1c4e51715`. The double-put is
confirmed present in the current code at lines 949-977 and 991-995.

### Step 6.2: BACKPORT COMPLICATIONS
The diff should apply cleanly or with minimal offset. The code context
matches the current tree state. The intervening `65b5c326ce410` commit
modifies different parts of the function.

### Step 6.3: RELATED FIXES IN STABLE
No other fix for this specific double-put issue exists in the stable
tree.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
- **Subsystem**: drm/amdgpu (AMD GPU driver) - IMPORTANT
- **Sub-component**: userqueue fence handling - used by userspace GPU
  workloads
- **Impact scope**: All AMD GPU users running userqueue-enabled
  applications

### Step 7.2: SUBSYSTEM ACTIVITY
The file has 48 commits and is actively developed. The userqueue feature
is relatively new (introduced late 2024), so this is actively used by
new GPU workloads.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
All users with AMD GPUs that use the userqueue IOCTL path (driver-
specific, but a major driver).

### Step 8.2: TRIGGER CONDITIONS
The bug triggers during normal GPU operations - the stack trace shows it
happening during `glxgears:cs0` workload via the signal ioctl path
walking reservation fences. Any userspace application exercising the
wait/signal ioctl path can trigger this.

### Step 8.3: FAILURE MODE SEVERITY
- **Primary**: `refcount_t: underflow; use-after-free` WARNING
- **Secondary**: Soft lockup (CPU stuck for 26s) in
  `dma_resv_iter_walk_unlocked`
- **Severity**: CRITICAL - system hang/lockup, potential data corruption
  from use-after-free

### Step 8.4: RISK-BENEFIT RATIO
- **BENEFIT**: Very high - prevents use-after-free, refcount underflow,
  and system hangs for AMD GPU users
- **RISK**: Very low - 4 net lines removed, no new logic, obviously
  correct, reviewed by the person who introduced the bug and by the
  subsystem maintainer
- **Ratio**: Extremely favorable

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: EVIDENCE COMPILATION

**FOR backporting:**
- Fixes a real, reproducible use-after-free and refcount underflow
- Causes system soft lockup (26 seconds) - CRITICAL severity
- Triggered via normal GPU ioctl usage path
- Extremely small and surgical (-4 net lines)
- Reviewed by 2 DRM experts (Tvrtko Ursulin, Christian König)
- Applied by subsystem maintainer (Alex Deucher)
- Bug-introducing commit (bea29bb0dd29/048c1c4e51715) is already in this
  stable tree
- Full stack trace demonstrating the crash on real hardware
- Standalone fix with no dependencies on other patches

**AGAINST backporting:**
- None identified

### Step 9.2: STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES - confirmed by author,
   reviewers, and the person who introduced the bug; tested on real
   hardware
2. **Fixes a real bug?** YES - double dma_fence_put causing use-after-
   free and soft lockup
3. **Important issue?** YES - system hang (soft lockup), use-after-free,
   refcount underflow
4. **Small and contained?** YES - 4 net lines removed in a single
   file/function
5. **No new features or APIs?** CORRECT - purely removes erroneous calls
6. **Can apply to stable trees?** YES - the buggy commit is present in
   this tree

### Step 9.3: EXCEPTION CATEGORIES
Not applicable - this is a standard critical bug fix.

### Step 9.4: DECISION
This is a textbook stable backport candidate: a small, obviously correct
fix for a critical bug (use-after-free + system hang) that was
introduced by a commit already present in the stable tree.

---

## Verification

- [Phase 1] Parsed commit message: explicit "fix" in subject, refcount
  underflow description, stack traces showing soft lockup and use-after-
  free warning
- [Phase 1] Tags: Reviewed-by Tvrtko Ursulin and Christian König;
  Signed-off-by Alex Deucher (maintainer)
- [Phase 2] Diff: removes 3 `dma_fence_put(fences[i])` calls from loop
  in `amdgpu_userq_wait_ioctl()`, -4 net lines
- [Phase 2] Cleanup path at `free_fences:` already calls
  `dma_fence_put()` on all fences, confirmed at lines 991-995
- [Phase 3] git blame: in-loop puts from commit 15e30a6e479282
  (2024-10-30); cleanup loop modified by 048c1c4e51715 (consolidation)
- [Phase 3] Consolidation commit `048c1c4e51715` confirmed present in
  7.0 tree (cherry-picked from bea29bb0dd29)
- [Phase 3] Current code at lines 949-977 confirmed still has the
  double-put (fix not yet applied)
- [Phase 3] Only one intervening commit (65b5c326ce410, refcount
  userqueues) which touches different code areas
- [Phase 4] Mailing list discussion found at
  https://lists.freedesktop.org/archives/amd-gfx/2026-March/140504.html
- [Phase 4] Tvrtko Ursulin confirmed the fix is correct and acknowledged
  he introduced the bug
- [Phase 4] Tvrtko provided the Fixes tag: `Fixes: bea29bb0dd29`
- [Phase 4] No NAKs, no objections; unanimous approval from reviewers
- [Phase 5] `amdgpu_userq_wait_ioctl()` is reachable from userspace
  ioctl syscall path
- [Phase 6] Bug-introducing commit IS in this stable tree
  (048c1c4e51715)
- [Phase 6] Fix should apply cleanly - code context matches
- [Phase 7] amdgpu is an IMPORTANT subsystem; userqueue fence code is
  actively developed
- [Phase 8] Failure: use-after-free + 26s soft lockup; severity
  CRITICAL; triggered during normal GPU operations

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
index 5239b06b9ab03..bb390067c26ef 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
@@ -947,12 +947,9 @@ int amdgpu_userq_wait_ioctl(struct drm_device *dev, void *data,
 				 * be good for now
 				 */
 				r = dma_fence_wait(fences[i], true);
-				if (r) {
-					dma_fence_put(fences[i]);
+				if (r)
 					goto free_fences;
-				}
 
-				dma_fence_put(fences[i]);
 				continue;
 			}
 
@@ -974,7 +971,6 @@ int amdgpu_userq_wait_ioctl(struct drm_device *dev, void *data,
 			fence_info[cnt].va = fence_drv->va;
 			fence_info[cnt].value = fences[i]->seqno;
 
-			dma_fence_put(fences[i]);
 			/* Increment the actual userq fence count */
 			cnt++;
 		}
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] drm/amdgpu: guard atom_context in devcoredump VBIOS dump

[Sasha Levin]

From: Jesse Zhang <Jesse.Zhang@amd.com>

[ Upstream commit 557fa5a453c9ccb49a22f30a7ad0545573d434b7 ]

During GPU reset coredump generation, amdgpu_devcoredump_fw_info() unconditionally
dereferences adev->mode_info.atom_context to print VBIOS fields. On reset/teardown
paths this pointer can be NULL, causing a kernel page fault from the deferred
coredump workqueue.

Fix by checking ctx before printing VBIOS fields:

if ctx is valid, print full VBIOS information as before;
This prevents NULL-dereference crashes while preserving coredump output.

Observed page fault log:
[  667.933329] RIP: 0010:amdgpu_devcoredump_format+0x780/0xc00 [amdgpu]
[  667.941517] amdgpu 0002:01:00.0: Dumping IP State
[  667.949660] Code: 8d 57 74 48 c7 c6 01 65 9f c2 48 8d 7d 98 e8 97 96 7a ff 49 8d 97 b4 00 00 00 48 c7 c6 18 65 9f c2 48 8d 7d 98 e8 80 96 7a ff <41> 8b 97 f4 00 00 00 48 c7 c6 2f 65 9f c2 48 8d 7d 98 e8 69 96 7a
[  667.949666] RSP: 0018:ffffc9002302bd50 EFLAGS: 00010246
[  667.949673] RAX: 0000000000000000 RBX: ffff888110600000 RCX: 0000000000000000
[  667.949676] RDX: 000000000000a9b5 RSI: 0000000000000405 RDI: 000000000000a999
[  667.949680] RBP: ffffc9002302be00 R08: ffffffffc09c3084 R09: ffffffffc09c3085
[  667.949684] R10: 0000000000000000 R11: 0000000000000004 R12: 00000000000048e0
[  667.993908] amdgpu 0002:01:00.0: Dumping IP State Completed
[  667.994229] R13: 0000000000000025 R14: 000000000000000c R15: 0000000000000000
[  667.994233] FS:  0000000000000000(0000) GS:ffff88c44c2c9000(0000) knlGS:0000000000000000
[  668.000076] amdgpu 0002:01:00.0: [drm] AMDGPU device coredump file has been created
[  668.008025] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  668.008030] CR2: 00000000000000f4 CR3: 000000011195f001 CR4: 0000000000770ef0
[  668.008035] PKRU: 55555554
[  668.008040] Call Trace:
[  668.008045]  <TASK>
[  668.016010] amdgpu 0002:01:00.0: [drm] Check your /sys/class/drm/card16/device/devcoredump/data
[  668.023967]  ? srso_alias_return_thunk+0x5/0xfbef5
[  668.023988]  ? __pfx___drm_printfn_coredump+0x10/0x10 [drm]
[  668.031950] amdgpu 0003:01:00.0: Dumping IP State
[  668.038159]  ? __pfx___drm_puts_coredump+0x10/0x10 [drm]
[  668.083017] amdgpu 0003:01:00.0: Dumping IP State Completed
[  668.083824]  amdgpu_devcoredump_deferred_work+0x26/0xc0 [amdgpu]
[  668.086163] amdgpu 0003:01:00.0: [drm] AMDGPU device coredump file has been created
[  668.095863]  process_scheduled_works+0xa6/0x420
[  668.095880]  worker_thread+0x12a/0x270
[  668.101223] amdgpu 0003:01:00.0: [drm] Check your /sys/class/drm/card24/device/devcoredump/data
[  668.107441]  kthread+0x10d/0x230
[  668.107451]  ? __pfx_worker_thread+0x10/0x10
[  668.107458]  ? __pfx_kthread+0x10/0x10
[  668.112709] amdgpu 0000:01:00.0: ring vcn_unified_1 timeout, signaled seq=9, emitted seq=10
[  668.118630]  ret_from_fork+0x17c/0x1f0
[  668.118640]  ? __pfx_kthread+0x10/0x10
[  668.118647]  ret_from_fork_asm+0x1a/0x30

Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Suggested-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Jesse Zhang <jesse.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a comprehensive analysis. Let
me compile the findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `drm/amdgpu`
- Action verb: "guard" — implies adding a missing safety check, which is
  a bug fix pattern
- Summary: Guard `atom_context` in devcoredump VBIOS dump to prevent
  NULL dereference

**Step 1.2: Tags**
- `Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>` — AMD GPU subsystem
  reviewer
- `Suggested-by: Lijo Lazar <lijo.lazar@amd.com>` — the fix approach was
  suggested by a maintainer
- `Signed-off-by: Jesse Zhang <jesse.zhang@amd.com>` — author, regular
  AMD GPU contributor
- `Signed-off-by: Alex Deucher <alexander.deucher@amd.com>` — AMD GPU
  subsystem maintainer who committed it
- No Fixes: tag (expected for autosel candidates)
- No Cc: stable (expected)

**Step 1.3: Commit Body**
- Bug: During GPU reset coredump generation,
  `amdgpu_devcoredump_fw_info()` unconditionally dereferences
  `adev->mode_info.atom_context` (via local `ctx` variable) to print
  VBIOS fields. On reset/teardown paths, this pointer can be NULL.
- Symptom: Kernel page fault from deferred coredump workqueue. The crash
  log with `CR2: 00000000000000f4` confirms access at offset 0xf4 from a
  NULL pointer.
- The RIP points to `amdgpu_devcoredump_format+0x780` and the call trace
  shows `amdgpu_devcoredump_deferred_work` → `process_scheduled_works` →
  `worker_thread`.

**Step 1.4: Hidden Bug Fix Detection**
- Not hidden — this is an explicit, documented crash fix with a full
  kernel oops log.

Record: This is a clear NULL pointer dereference fix with observed crash
evidence.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Files changed: 1 (`drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c`)
- Lines: +10, -6 (net +4 lines)
- Functions modified: `amdgpu_devcoredump_fw_info()`
- Scope: Single-file surgical fix

**Step 2.2: Code Flow Change**
- BEFORE: Lines 190-195 unconditionally dereference `ctx->name`,
  `ctx->vbios_pn`, `ctx->version`, `ctx->vbios_ver_str`, `ctx->date`
- AFTER: Wrapped in `if (adev->bios)` — if BIOS is available, print full
  VBIOS info; if not, print "VBIOS Information: NA"

**Step 2.3: Bug Mechanism**
Category: **Memory safety — NULL pointer dereference**
- `ctx` is assigned at line 79: `struct atom_context *ctx =
  adev->mode_info.atom_context;`
- `atom_context` is set to NULL by `amdgpu_atombios_fini()` (line 1882
  of `amdgpu_atombios.c`) during teardown
- `adev->bios` is set to NULL by `amdgpu_bios_release()` (line 90 of
  `amdgpu_bios.c`)
- Both are called from `amdgpu_device_fini_sw()` at lines 4984-4988 of
  `amdgpu_device.c`
- The guard uses `adev->bios` because Lijo explained that if BIOS is
  unavailable (skip_bios platforms), atom_context won't exist — this is
  a non-error case

**Step 2.4: Fix Quality**
- Obviously correct: simple NULL guard
- Minimal and surgical: only the VBIOS section is wrapped
- No regression risk: doesn't change any logic, just prevents access to
  NULL pointer
- The `adev->bios` check is the correct proxy per maintainer guidance

Record: Clean NULL guard fix, 4 net lines added, zero regression risk.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
- Lines 190 (header print) introduced by commit `6a0e1bafd70fe5` (Sunil
  Khatri, 2024-03-26) — "drm/amdgpu: add IP's FW information to
  devcoredump"
- Lines 191-195 (ctx dereferences) introduced by commit `3c858cf65e9a2c`
  (Sunil Khatri, 2024-04-12) — "drm/amdgpu: add missing vbios version
  from devcoredump"
- Both first appeared in `v6.10-rc1`

**Step 3.2: Fixes tag**
- No Fixes: tag present. Based on analysis, would fix `3c858cf65e9a2c`
  which added the `ctx->*` dereferences.

**Step 3.3: File History**
- 14 commits to this file since `6a0e1bafd70fe5`, mostly feature
  additions (IP dump, ring buffer info, device info)
- No prior fix for this specific NULL dereference

**Step 3.4: Author**
- Jesse Zhang is a regular AMD GPU contributor (10 recent commits to
  amdgpu subsystem found)
- Fix was suggested and reviewed by Lijo Lazar (AMD GPU maintainer)

**Step 3.5: Dependencies**
- Standalone fix, no dependencies on other patches

Record: Buggy code from v6.10-rc1. Fix is standalone with no
prerequisites.

---

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Patch Discussion**
Found the full evolution on amd-gfx mailing list:
- **V1**: Checked `ctx` directly before VBIOS access
- **V2** (mail-archive.com/amd-
  gfx@lists.freedesktop.org/msg139678.html): Still checked `ctx`, added
  `!adev->bios` check per Lijo's initial feedback
- **Lijo's V2 review**: "On a second check, this cannot happen when
  vbios is available. Driver load will fail in that case. In other
  cases, we operate without VBIOS. For them, probably this may be
  avoided altogether (preferred) or mark the section as NA." Suggested
  `drm_printf(p, "\nVBIOS Information: NA\n");`
- **V3 (committed)**: Jesse incorporated Lijo's feedback — checks
  `adev->bios` and prints "VBIOS Information: NA"

**Step 4.2: Reviewers**
- Lijo Lazar (AMD GPU reviewer) reviewed all versions and provided the
  fix approach
- Alex Deucher (AMD GPU maintainer) signed off and committed

**Step 4.3: Bug Report**
- No external bug report link, but the commit includes a complete kernel
  oops log, confirming reproduction

Record: Patch went through 3 revisions with constructive review. Final
version incorporates maintainer's preferred approach.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions Modified**
- `amdgpu_devcoredump_fw_info()` — static helper to print firmware info
  in coredump

**Step 5.2: Callers**
- Called from `amdgpu_devcoredump_read()` (line 266 in 7.0 tree), which
  is the devcoredump read callback passed to `dev_coredumpm()`
- Triggered when the devcoredump deferred work runs or when userspace
  reads `/sys/class/drm/cardN/device/devcoredump/data`

**Step 5.3: Trigger Path**
- GPU reset → `amdgpu_coredump()` → `dev_coredumpm()` → (later) deferred
  work or userspace read → `amdgpu_devcoredump_read()` →
  `amdgpu_devcoredump_fw_info()` → **CRASH** if atom_context is NULL

**Step 5.4: Reachability**
- GPU resets happen automatically on GPU hang recovery — very common for
  AMDGPU users
- The coredump path is always active when `CONFIG_DEV_COREDUMP` is
  enabled (default in most distros)

Record: The crash path is reachable from normal GPU hang recovery
operations.

---

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable**
- The buggy code was introduced in v6.10-rc1
- Affects all stable trees from 6.10 onwards: 6.10.y, 6.11.y, 6.12.y,
  6.13.y, 6.14.y, and this 7.0 tree

**Step 6.2: Backport Complications**
- The actual changed code (VBIOS section in
  `amdgpu_devcoredump_fw_info()`) is identical in the 7.0 tree and the
  upstream version
- The diff's trailing context shows `amdgpu_devcoredump_format` but the
  7.0 tree has `amdgpu_devcoredump_read` — this is just context, not the
  changed hunk, so it only requires minor fuzz adjustment

**Step 6.3: Related Fixes Already in Stable**
- No related fixes found for this specific issue

Record: Fix applies to all stable trees 6.10+. Minor context adjustment
needed for 7.0 tree.

---

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem**
- `drm/amdgpu` — AMD GPU driver
- Criticality: **IMPORTANT** — AMDGPU is one of the most widely used GPU
  drivers (all AMD Radeon GPUs, both discrete and integrated)

**Step 7.2: Activity**
- Very actively developed subsystem with frequent commits

Record: IMPORTANT subsystem affecting a large user base.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
- All users with AMD GPUs running kernels 6.10+ with
  `CONFIG_DEV_COREDUMP` enabled (most distros)

**Step 8.2: Trigger Conditions**
- GPU hang → automatic reset → coredump generation with `atom_context`
  already freed
- GPU hangs and resets are common real-world events
- Does not require unprivileged user action (happens automatically)

**Step 8.3: Failure Mode**
- Kernel page fault (oops) from workqueue context
- CR2: 0xf4 — NULL pointer dereference at struct offset 0xf4
- Severity: **HIGH** (kernel oops, system instability)

**Step 8.4: Risk-Benefit Ratio**
- **Benefit**: HIGH — prevents kernel crash during GPU reset recovery
- **Risk**: VERY LOW — 10-line NULL guard, single function, reviewed by
  maintainer, obviously correct
- **Ratio**: Strongly favorable for backporting

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Summary**

FOR backporting:
- Fixes a real, observed kernel oops (full stack trace provided)
- Small, surgical fix (4 net lines changed in one function)
- Reviewed and suggested by AMD GPU maintainer (Lijo Lazar)
- Signed off by subsystem maintainer (Alex Deucher)
- Went through 3 review revisions — well-vetted
- Affects widely-used AMDGPU driver
- Bug present since v6.10 — affects all active stable trees
- Zero regression risk — just a NULL guard
- Standalone fix with no dependencies

AGAINST backporting:
- None identified
- Minor context adjustment may be needed for backport (function name in
  trailing context differs)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — simple NULL guard, reviewed
   by maintainer
2. Fixes a real bug? **YES** — kernel oops during GPU reset
3. Important issue? **YES** — kernel crash (oops)
4. Small and contained? **YES** — 10 lines changed, single file, single
   function
5. No new features or APIs? **YES** — only adds a safety check
6. Can apply to stable? **YES** — with minor context adjustment

**Step 9.3: Exception Categories**
- Not an exception category; this is a standard bug fix that qualifies
  on its own merits.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by and Suggested-by from Lijo Lazar
  (AMD reviewer), Signed-off-by from Alex Deucher (maintainer)
- [Phase 2] Diff analysis: wraps 6 `ctx->*` dereferences with `if
  (adev->bios)` guard in `amdgpu_devcoredump_fw_info()`
- [Phase 3] git blame: buggy dereferences introduced in commits
  `6a0e1bafd70fe5` and `3c858cf65e9a2c`, both in v6.10-rc1
- [Phase 3] `git describe --contains 6a0e1bafd70fe5`: confirmed
  `v6.10-rc1~148^2~21^2~118`
- [Phase 3] `git describe --contains 3c858cf65e9a2c`: confirmed
  `v6.10-rc1~148^2~19^2~49`
- [Phase 4] mail-archive.com V2 thread: Lijo reviewed, suggested
  `adev->bios` check and "NA" fallback
- [Phase 4] mail-archive.com Jesse's response: confirmed V3 incorporates
  Lijo's feedback
- [Phase 5] Grep for `amdgpu_devcoredump_fw_info` callers: called from
  `amdgpu_devcoredump_read()` line 266
- [Phase 5] Grep for `amdgpu_atombios_fini`: confirmed `atom_context =
  NULL` at line 1882 of `amdgpu_atombios.c`
- [Phase 5] Grep for `amdgpu_bios_release`: confirmed `adev->bios =
  NULL` at line 90 of `amdgpu_bios.c`
- [Phase 5] Confirmed both called from `amdgpu_device.c` lines 4984-4988
  during teardown
- [Phase 6] Code exists in 7.0 tree — lines 190-195 of
  `amdgpu_dev_coredump.c` show identical buggy code
- [Phase 6] Function name difference in context (`format` vs `read`) is
  only in trailing context, not the changed hunk
- [Phase 8] Failure mode: NULL deref → kernel oops from workqueue during
  GPU reset, severity HIGH

---

The fix is small, surgical, obviously correct, well-reviewed by AMD GPU
maintainers, and prevents a real kernel oops triggered during normal GPU
reset recovery. It meets all stable kernel criteria with minimal risk.

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c
index c38e7371bafce..fed4e73d3492f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c
@@ -187,12 +187,16 @@ static void amdgpu_devcoredump_fw_info(struct amdgpu_device *adev,
 	drm_printf(p, "VPE feature version: %u, fw version: 0x%08x\n",
 		   adev->vpe.feature_version, adev->vpe.fw_version);
 
-	drm_printf(p, "\nVBIOS Information\n");
-	drm_printf(p, "vbios name       : %s\n", ctx->name);
-	drm_printf(p, "vbios pn         : %s\n", ctx->vbios_pn);
-	drm_printf(p, "vbios version    : %d\n", ctx->version);
-	drm_printf(p, "vbios ver_str    : %s\n", ctx->vbios_ver_str);
-	drm_printf(p, "vbios date       : %s\n", ctx->date);
+	if (adev->bios) {
+		drm_printf(p, "\nVBIOS Information\n");
+		drm_printf(p, "vbios name       : %s\n", ctx->name);
+		drm_printf(p, "vbios pn         : %s\n", ctx->vbios_pn);
+		drm_printf(p, "vbios version    : %d\n", ctx->version);
+		drm_printf(p, "vbios ver_str    : %s\n", ctx->vbios_ver_str);
+		drm_printf(p, "vbios date       : %s\n", ctx->date);
+	}else {
+		drm_printf(p, "\nVBIOS Information: NA\n");
+	}
 }
 
 static ssize_t
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] drm/amd/display: Avoid turning off the PHY when OTG is running for DVI

[Sasha Levin]

From: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>

[ Upstream commit ee212b0208a18831d2b537865da56708c17af90d ]

[Why]
The OTG's virtual pixel clock source for DVI comes from the PHY.

If the signal type is DVI then the OTG can become stuck on pre DCN401
ASIC when DPMS off occurs because the OTG remains running but the
PHY transmitter is disabled.

[How]
There exists logic to keep track of the OTG running refcount on the
link to determine if the link needs to go to PLL_EN instead of TX_EN
but the logic only checks for HDMI TMDS on older ASIC.

DVI is still a TMDS signal type so the constraint should also apply.

Replace the checks for dc_is_hdmi_tmds_signal with dc_is_tmds_signal to
cover both HDMI and DVI for the symclk refcount workaround.

Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Reviewed-by: Charlene Liu <charlene.liu@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for the complete analysis. Let me
compile everything.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem:** drm/amd/display (AMD display driver)
- **Action verb:** "Avoid" (implies preventing an undesirable condition
  - strong bug fix indicator)
- **Summary:** Prevent PHY from being turned off when OTG is running for
  DVI signals

Record: [drm/amd/display] [Avoid] [Prevents PHY shutdown while OTG is
running for DVI, which causes OTG to get stuck]

### Step 1.2: Tags
- **Reviewed-by:** Dillon Varone <dillon.varone@amd.com> - AMD display
  team member
- **Reviewed-by:** Charlene Liu <charlene.liu@amd.com> - AMD display
  team member (senior contributor)
- **Signed-off-by:** Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> -
  Author, prolific AMD display contributor
- **Signed-off-by:** Chuanyu Tseng <chuanyu.tseng@amd.com> - Co-
  author/submitter
- **Signed-off-by:** Alex Deucher <alexander.deucher@amd.com> - AMD DRM
  maintainer
- No Fixes: tag, no Cc: stable (expected for autosel candidates)

Record: Two Reviewed-by from AMD display engineers. Author is an active
AMD display subsystem contributor with many commits. Applied by the
subsystem maintainer.

### Step 1.3: Commit Body Analysis
**Bug description:** On pre-DCN401 ASICs, when using a DVI output, DPMS
off causes the PHY transmitter to be disabled while the OTG (Output
Timing Generator) is still running. The OTG's virtual pixel clock source
for DVI comes from the PHY, so disabling the PHY causes the OTG to
become stuck.

**Root cause:** The symclk reference count tracking logic that prevents
premature PHY shutdown only checked for HDMI TMDS signals
(`dc_is_hdmi_tmds_signal`), but DVI is also a TMDS signal type that has
the same clock dependency.

**Fix approach:** Replace `dc_is_hdmi_tmds_signal` with
`dc_is_tmds_signal` to cover both HDMI and DVI signal types.

Record: Hardware hang bug on DVI output during DPMS off. OTG gets stuck
because PHY providing its clock is disabled. Root cause is incomplete
signal type check. Severity: CRITICAL (system hang).

### Step 1.4: Hidden Bug Fix Detection
This is NOT a hidden bug fix - it's explicitly described as preventing a
hardware hang condition. The commit clearly articulates the bug
mechanism, root cause, and fix.

Record: Explicitly described bug fix, not disguised.

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **dce110_hwseq.c**: 2 lines changed (line 1571, line 2421)
- **dcn20_hwseq.c**: 2 lines changed (line 896, line 2859)
- **dcn31_hwseq.c**: 1 line changed (line 552)
- **dcn401_hwseq.c**: 1 line changed (line 2024)
- **Total**: 6 single-line changes across 4 files
- **Functions modified:** `dce110_enable_stream_timing`,
  `dce110_reset_hw_ctx_wrap`, `dcn20_enable_stream_timing`,
  `dcn20_reset_back_end_for_pipe`, `dcn31_reset_back_end_for_pipe`,
  `dcn401_reset_back_end_for_pipe`
- **Scope:** Small, surgical, single-purpose

Record: 6 lines changed, 4 files, all changes are identical substitution
of one function call for another.

### Step 2.2: Code Flow Change
Every change is identical: `dc_is_hdmi_tmds_signal()` ->
`dc_is_tmds_signal()`.

- `dc_is_hdmi_tmds_signal()`: returns true only for
  `SIGNAL_TYPE_HDMI_TYPE_A`
- `dc_is_tmds_signal()`: returns true for `SIGNAL_TYPE_DVI_SINGLE_LINK`,
  `SIGNAL_TYPE_DVI_DUAL_LINK`, AND `SIGNAL_TYPE_HDMI_TYPE_A`

The change extends the signal check to include DVI signals in addition
to HDMI. This ensures:
1. **Enable path**: symclk_ref_cnts.otg is set to 1 and symclk_state is
   properly tracked for DVI (not just HDMI)
2. **Disable/reset path**: symclk_ref_cnts.otg is properly cleared for
   DVI, enabling the proper PHY shutdown sequence

Record: Before: Only HDMI gets symclk tracking. After: Both HDMI and DVI
get symclk tracking. This prevents PHY shutdown while OTG still needs
the clock.

### Step 2.3: Bug Mechanism
**Category:** Hardware hang / OTG stuck due to clock dependency
- The OTG needs a clock from the PHY for TMDS signals (both HDMI and
  DVI)
- Without proper symclk reference counting for DVI, the PHY could be
  powered off while the OTG is still running
- This causes the OTG to become stuck (hardware hang)

Record: Hardware hang in DPMS off path for DVI output on pre-DCN401
ASICs. The fix extends symclk ref counting to cover all TMDS signals.

### Step 2.4: Fix Quality
- **Obviously correct:** YES - `dc_is_tmds_signal` is a strict superset
  of `dc_is_hdmi_tmds_signal`, and the commit message clearly explains
  why DVI needs the same treatment
- **Minimal/surgical:** YES - 6 identical one-line substitutions
- **Regression risk:** Very low - the only behavioral change is that DVI
  now gets symclk tracking (which it should have had). For HDMI,
  behavior is unchanged. For non-TMDS signals, behavior is unchanged.
- **Red flags:** None

Record: Fix is obviously correct, minimal, and very low regression risk.

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
The buggy code (`dc_is_hdmi_tmds_signal` used for symclk tracking) was
introduced by commit `9c75891feef0f9` ("drm/amd/display: rework recent
update PHY state commit") by Wenjing Liu, which went into v6.1-rc1. This
commit introduced the symclk reference counting workaround but only for
HDMI TMDS signals.

Record: Buggy code introduced in v6.1-rc1 by commit 9c75891feef0f9.
Present in all stable trees >= v6.1.

### Step 3.2: Fixes Tag
No explicit Fixes: tag present (expected for autosel candidate).
However, the implicit fix target is `9c75891feef0f9` which is present
since v6.1-rc1.

Record: Implicitly fixes 9c75891feef0f9 (v6.1-rc1).

### Step 3.3: File History
Related commits in the same area:
- `dff45f03f508` (v6.8-rc1): "Only clear symclk otg flag for HDMI" -
  this was a NARROWING of the check (from unconditional to HDMI-only) to
  fix a SubVP phantom pipe issue. It actually made the DVI bug worse by
  adding the hdmi-only condition to the reset path too.
- `4589712e01113`: "Ensure link output is disabled in backend reset for
  PLL_ON" - ports DCN401 behavior to DCN31
- `75372d75a4e23`: "Adjust PHY FSM transition to TX_EN-to-PLL_ON for
  TMDS on DCN35" - related PHY FSM fix

Record: The fix is standalone. No prerequisites needed beyond the
already-present code.

### Step 3.4: Author
Nicholas Kazlauskas is a prolific AMD display contributor (20+ commits
in the hwss directory alone) with deep knowledge of the PHY state
machine and clock management. He authored the DCN35 TMDS fix and the
link output disable fix as well.

Record: Author is a core AMD display contributor with extensive
subsystem expertise.

### Step 3.5: Dependencies
The patch is self-contained. It only changes function calls that already
exist. Both `dc_is_tmds_signal` and `dc_is_hdmi_tmds_signal` have been
in the codebase since well before v6.1. No new functions, structures, or
APIs are introduced.

Record: No dependencies. Applies standalone.

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Steps 4.1-4.5
b4 is not available and lore.kernel.org blocks automated access. Web
search found:
- The related DCN35 PHY FSM fix was submitted as part of a 21-patch
  series
- The "Ensure link output is disabled in backend reset for PLL_ON" fix
  was also part of stable backport discussions
- Both related fixes were included in stable backport attempts (6.19
  stable patches)

Record: Related fixes in the same PHY/OTG area have been submitted for
stable. The commit was reviewed by two AMD engineers and the maintainer.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Functions Modified
1. `dce110_enable_stream_timing` - used by DCE110 hardware
2. `dce110_reset_hw_ctx_wrap` - used by DCE110 hardware
3. `dcn20_enable_stream_timing` - shared by DCN20, DCN21, DCN30, DCN301,
   DCN31, DCN314, DCN32, DCN35, DCN351
4. `dcn20_reset_back_end_for_pipe` - used by DCN20, DCN21, DCN30,
   DCN301, DCN32
5. `dcn31_reset_back_end_for_pipe` - used by DCN31, DCN314, DCN35,
   DCN351
6. `dcn401_reset_back_end_for_pipe` - used by DCN401

Record: The fix covers the majority of AMD display hardware generations.

### Step 5.2: Callers
These functions are called during display mode set and DPMS operations -
common display operations triggered by user actions
(connecting/disconnecting monitors, screen off/on, suspend/resume).

Record: Functions are called in normal display operation paths - common
trigger.

### Step 5.3-5.5
The `dc_is_tmds_signal` function already exists and is used correctly in
other parts of the DCN401 code (lines 711, 740, 747, 936, 1063),
confirming the pattern. The DCN35 code also uses `dc_is_tmds_signal`
correctly (line 1765). The inconsistency is specifically in the symclk
tracking code in the older HWSEQ implementations.

Record: Pattern is consistent with existing correct usage in DCN35 and
DCN401.

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Code in Stable
The buggy code was introduced in v6.1-rc1 by `9c75891feef0f9`. It exists
in all active stable trees >= v6.1.

Record: Buggy code present in stable trees 6.1.y, 6.6.y, 6.12.y.

### Step 6.2: Backport Complications
The fix only changes function call names in-place. No structural changes
to the surrounding code are needed. The 4 files modified have been
present since v6.1. The `dc_is_tmds_signal` function has existed since
before v6.1.

Note: For older stable trees (6.1, 6.6), the dcn401_hwseq.c file may not
exist (DCN401 was added later). The patch would need to be trimmed for
those trees, but the other 3 files should apply cleanly or with minimal
fuzz.

Record: Should apply cleanly to 6.12.y. May need minor trimming for
6.1.y and 6.6.y (dcn401 file may not exist).

### Step 6.3: No related fix already in stable for this specific DVI
issue.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1
**Subsystem:** drm/amd/display - AMD GPU display driver
**Criticality:** IMPORTANT - affects all AMD GPU users with DVI
connections

### Step 7.2
The AMD display subsystem is very actively developed with constant
updates.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
All AMD GPU users with DVI monitors on pre-DCN401 hardware (which covers
the vast majority of AMD GPUs supporting DVI).

### Step 8.2: Trigger Conditions
- Trigger: DPMS off on a DVI-connected display (screen blank, suspend,
  monitor power off)
- This is a common operation that any DVI user would hit
- Not timing-dependent or race-related - deterministic bug

### Step 8.3: Severity
**CRITICAL** - OTG becomes stuck (hardware hang). The commit message
from the related DCN35 fix mentions this can "lead to a hang in the
DCHVM's ability to ACK invalidations" which can trigger IOMMU watchdog
timeouts.

### Step 8.4: Risk-Benefit
**Benefit:** HIGH - Prevents hardware hang for all DVI users on AMD GPUs
**Risk:** VERY LOW - 6 one-line changes, each a simple function
substitution to a well-tested superset function. Existing HDMI behavior
is 100% unchanged.

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting:**
- Fixes a hardware hang (OTG stuck) for DVI users - CRITICAL severity
- Deterministic trigger during common operation (DPMS off)
- Fix is minimal: 6 identical one-line substitutions
- Obviously correct: `dc_is_tmds_signal` is a superset that covers both
  DVI and HDMI
- Pattern already used correctly in newer code (DCN401 enable path,
  DCN35)
- Two Reviewed-by from AMD engineers
- Author is a core AMD display contributor
- Buggy code exists in all stable trees >= v6.1
- Self-contained, no dependencies
- Very low regression risk

**AGAINST backporting:**
- Touches 4 files (but changes are minimal and identical in nature)
- DCN401 file may not exist in older stable trees (minor backport
  trimming needed)
- No explicit Cc: stable or Fixes: tag (expected for autosel)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** - Reviewed by 2 AMD engineers,
   obviously correct from code analysis
2. Fixes a real bug? **YES** - Hardware hang for DVI users during DPMS
   off
3. Important issue? **YES** - System hang/stuck OTG, CRITICAL severity
4. Small and contained? **YES** - 6 one-line changes, purely mechanical
   substitution
5. No new features or APIs? **YES** - No new features, just extends
   existing check to cover DVI
6. Can apply to stable trees? **YES** - may need DCN401 hunk dropped for
   older trees

### Step 9.3: Exception Categories
Not an exception category - this is a straightforward bug fix.

### Step 9.4: Decision
This is a clear YES. It fixes a CRITICAL hardware hang for DVI users on
AMD GPUs, the fix is minimal and obviously correct, it has been reviewed
by AMD engineers, and it carries very low regression risk.

## Verification

- [Phase 1] Parsed tags: 2x Reviewed-by (AMD engineers), Signed-off-by
  author is active AMD contributor
- [Phase 2] Diff analysis: 6 one-line changes across 4 files, each
  replacing `dc_is_hdmi_tmds_signal` with `dc_is_tmds_signal`
- [Phase 2] Verified `dc_is_hdmi_tmds_signal` only matches HDMI_TYPE_A;
  `dc_is_tmds_signal` matches DVI_SINGLE_LINK, DVI_DUAL_LINK, and
  HDMI_TYPE_A (confirmed from signal_types.h)
- [Phase 3] git blame: buggy code introduced in commit 9c75891feef0f9
  (v6.1-rc1) by Wenjing Liu
- [Phase 3] Verified `dc_is_tmds_signal` function exists in
  signal_types.h since before v6.1
- [Phase 3] Found related commit dff45f03f508 (v6.8-rc1) that added
  hdmi-only condition to reset path for SubVP workaround
- [Phase 3] Author Nicholas Kazlauskas has 20+ commits in hwss directory
- [Phase 4] Web search confirmed related PHY/OTG fixes (DCN35 TMDS,
  backend reset PLL_ON) were submitted for stable
- [Phase 5] Verified `dcn20_enable_stream_timing` is shared by
  DCN20/21/30/301/31/314/32/35/351 via init.c files
- [Phase 5] Verified DCN401 already uses `dc_is_tmds_signal` at lines
  711, 740, 747, 936, 1063 - confirming correct pattern
- [Phase 6] Buggy code confirmed present since v6.1-rc1, exists in all
  active stable trees
- [Phase 6] Fix is self-contained - no new functions/structures
  introduced
- [Phase 8] Trigger: deterministic on DPMS off for DVI. Severity:
  CRITICAL (OTG hang)
- UNVERIFIED: Exact behavior of the OTG hang (whether it requires power
  cycle recovery) - but the related DCN35 fix mentions IOMMU watchdog
  timeouts, suggesting severe impact

**YES**

 drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c | 4 ++--
 drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c   | 4 ++--
 drivers/gpu/drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c   | 2 +-
 drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c
index 699a756bbc405..9e7085057f8ba 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c
@@ -1534,7 +1534,7 @@ static enum dc_status dce110_enable_stream_timing(
 			return DC_ERROR_UNEXPECTED;
 		}
 
-		if (dc_is_hdmi_tmds_signal(stream->signal)) {
+		if (dc_is_tmds_signal(stream->signal)) {
 			stream->link->phy_state.symclk_ref_cnts.otg = 1;
 			if (stream->link->phy_state.symclk_state == SYMCLK_OFF_TX_OFF)
 				stream->link->phy_state.symclk_state = SYMCLK_ON_TX_OFF;
@@ -2334,7 +2334,7 @@ static void dce110_reset_hw_ctx_wrap(
 				BREAK_TO_DEBUGGER();
 			}
 			pipe_ctx_old->stream_res.tg->funcs->disable_crtc(pipe_ctx_old->stream_res.tg);
-			if (dc_is_hdmi_tmds_signal(pipe_ctx_old->stream->signal))
+			if (dc_is_tmds_signal(pipe_ctx_old->stream->signal))
 				pipe_ctx_old->stream->link->phy_state.symclk_ref_cnts.otg = 0;
 			pipe_ctx_old->plane_res.mi->funcs->free_mem_input(
 					pipe_ctx_old->plane_res.mi, dc->current_state->stream_count);
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
index 307e8f8060e6d..a673ab0803a8f 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
@@ -893,7 +893,7 @@ enum dc_status dcn20_enable_stream_timing(
 		dccg->funcs->set_dtbclk_dto(dccg, &dto_params);
 	}
 
-	if (dc_is_hdmi_tmds_signal(stream->signal)) {
+	if (dc_is_tmds_signal(stream->signal)) {
 		stream->link->phy_state.symclk_ref_cnts.otg = 1;
 		if (stream->link->phy_state.symclk_state == SYMCLK_OFF_TX_OFF)
 			stream->link->phy_state.symclk_state = SYMCLK_ON_TX_OFF;
@@ -2856,7 +2856,7 @@ void dcn20_reset_back_end_for_pipe(
 		 * the case where the same symclk is shared across multiple otg
 		 * instances
 		 */
-		if (dc_is_hdmi_tmds_signal(pipe_ctx->stream->signal))
+		if (dc_is_tmds_signal(pipe_ctx->stream->signal))
 			link->phy_state.symclk_ref_cnts.otg = 0;
 		if (link->phy_state.symclk_state == SYMCLK_ON_TX_OFF) {
 			link_hwss->disable_link_output(link,
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c
index db2f7cbb12ff5..d6b027c06205e 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c
@@ -549,7 +549,7 @@ static void dcn31_reset_back_end_for_pipe(
 	 * the case where the same symclk is shared across multiple otg
 	 * instances
 	 */
-	if (dc_is_hdmi_tmds_signal(pipe_ctx->stream->signal))
+	if (dc_is_tmds_signal(pipe_ctx->stream->signal))
 		link->phy_state.symclk_ref_cnts.otg = 0;
 
 	if (pipe_ctx->top_pipe == NULL) {
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c
index a3d33d10853b8..9d9dcd2dd5fae 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c
@@ -2040,7 +2040,7 @@ void dcn401_reset_back_end_for_pipe(
 		 * the case where the same symclk is shared across multiple otg
 		 * instances
 		 */
-		if (dc_is_hdmi_tmds_signal(pipe_ctx->stream->signal))
+		if (dc_is_tmds_signal(pipe_ctx->stream->signal))
 			link->phy_state.symclk_ref_cnts.otg = 0;
 		if (link->phy_state.symclk_state == SYMCLK_ON_TX_OFF) {
 			link_hwss->disable_link_output(link,
-- 
2.53.0

[PATCH AUTOSEL 7.0] drm/amdgpu: Revert setting up Retry based Thrashing on GFX 12.1

[Sasha Levin]

From: Sreekant Somasekharan <Sreekant.Somasekharan@amd.com>

[ Upstream commit 29756a7535facdaed39d0b5572201068a7746812 ]

Bug found with retry based thrashing mechanism. Revert to the old
thrashing method.

Signed-off-by: Sreekant Somasekharan <Sreekant.Somasekharan@amd.com>
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have enough information to complete the full analysis. Let me
compile everything.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem:** drm/amdgpu (AMD GPU driver)
- **Action verb:** "Revert" - undoing a previous feature that's buggy
- **Summary:** Revert the retry-based thrashing prevention mechanism on
  GFX 12.1 hardware

### Step 1.2: Tags
- **Signed-off-by:** Sreekant Somasekharan (AMD employee, author)
- **Reviewed-by:** Mukul Joshi (the original author of the reverted
  feature)
- **Signed-off-by:** Alex Deucher (AMD GPU subsystem maintainer)
- No Fixes:, Reported-by:, Cc: stable, or Link: tags (expected for
  autosel candidates)

### Step 1.3: Commit Body
The message says: "Bug found with retry based thrashing mechanism.
Revert to the old thrashing method." This is terse, but the prior revert
of the same mechanism (commit `127770bcfccc2`) was more explicit:
"causing **data mismatch and slowness issues with multiple HIP tests**."
Data mismatch is a data corruption symptom.

### Step 1.4: Hidden Bug Fix?
This is an explicit revert of a buggy hardware feature enablement. No
hidden fix — it's straightforward.

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files:** 1 file modified: `drivers/gpu/drm/amd/amdgpu/gfx_v12_1.c`
- **Lines:** 0 added, 19 removed (pure deletion)
- **Functions modified:**
  - `gfx_v12_1_xcc_setup_tcp_thrashing_ctrl` (entirely removed)
  - `gfx_v12_1_init_golden_registers` (one call removed)
- **Scope:** Single-file surgical removal

### Step 2.2: Code Flow Change
- **Before:** `gfx_v12_1_init_golden_registers()` called
  `gfx_v12_1_xcc_setup_tcp_thrashing_ctrl()` for each XCC, which
  programmed the TCP_UTCL0_THRASHING_CTRL register with retry-based
  thrashing settings (THRASHING_EN=0x2,
  RETRY_FRAGMENT_THRESHOLD_UP_EN=1, RETRY_FRAGMENT_THRESHOLD_DOWN_EN=1)
- **After:** That function and its call are removed. The hardware's
  default (non-retry-based) thrashing prevention is used instead.

### Step 2.3: Bug Mechanism
This is a **hardware workaround** — the retry-based thrashing mode in
GFX 12.1's TCP UTCL0 has bugs causing data mismatch and performance
issues. Reverting to the old thrashing method avoids triggering the
hardware bug.

### Step 2.4: Fix Quality
- Obviously correct: pure deletion of a function and its call site
- Minimal/surgical: only removes the problematic code, nothing else
  changes
- Regression risk: essentially zero — only reverts to the previous
  (working) behavior
- Reviewed by the feature's original author

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
The buggy function `gfx_v12_1_xcc_setup_tcp_thrashing_ctrl` was
introduced in commit `a41d94a7bb962` ("Setup Retry based thrashing
prevention on GFX 12.1") by Mukul Joshi. This commit IS in v7.0.

### Step 3.2: Fixes Tag
No Fixes: tag present. However, this commit effectively fixes/reverts
`a41d94a7bb962`.

### Step 3.3: File History
The history reveals a pattern:
1. An earlier version of retry-based thrashing was in the original file
2. It was reverted in `127770bcfccc2` due to "data mismatch and slowness
   issues with multiple HIP tests"
3. It was re-added with different register settings in `a41d94a7bb962`
4. This commit (`29756a7535fac`) reverts it again because bugs persist

### Step 3.4: Author Context
Sreekant Somasekharan is an AMD employee working on the AMDGPU driver.
The reviewer Mukul Joshi is the author of both the feature and the first
revert. Alex Deucher is the subsystem maintainer.

### Step 3.5: Dependencies
The revert is standalone — it removes code without requiring any other
changes. It will apply cleanly to v7.0 as verified by checking the exact
state of the file in v7.0.

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1-4.5
b4 dig could not find the patch on lore.kernel.org (both for the revert
and the original commit). This is common for AMD GPU patches that may go
through internal review or GitLab merge requests. Web searches also did
not find the specific patch thread.

The related patch "gfx 12.1 cleanups" (found on spinics.net) confirms
this file was actively being cleaned up in the same timeframe,
validating that GFX 12.1 support was being actively refined.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.4
- `gfx_v12_1_xcc_setup_tcp_thrashing_ctrl` is called from
  `gfx_v12_1_init_golden_registers`
- `gfx_v12_1_init_golden_registers` is called from `gfx_v12_1_hw_init` —
  the hardware initialization path during GPU probe/resume
- This is a **normal initialization path** hit every time the GPU is
  initialized (boot, resume, GPU reset)
- The buggy register programming affects all GFX 12.1 users on every GPU
  init

### Step 5.5: Similar Patterns
The TCP_UTCL0_THRASHING_CTRL register only exists in GFX 12.1 headers.
No other GFX versions use this specific register in the same way.

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Does the buggy code exist in stable?
- `gfx_v12_1.c` does **NOT exist** in v6.12, v6.13, or v6.19 (verified
  via `git show v6.X:...`)
- The file was introduced during the v7.0-rc1 cycle
- The buggy commit `a41d94a7bb962` **IS in v7.0** (verified via `git
  merge-base --is-ancestor`)
- The revert `29756a7535fac` is **NOT in v7.0** (verified)
- **Only v7.0.y stable is affected**

### Step 6.2: Backport Complications
The patch should apply cleanly — the state of
`gfx_v12_1_init_golden_registers` in v7.0 exactly matches the diff
context (verified by examining the v7.0 tree).

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1
- **Subsystem:** GPU driver (drm/amdgpu) — IMPORTANT for AMD GPU users
- GFX 12.1 is new AMD hardware (likely RDNA/CDNA generation)

### Step 7.2
The file has extremely active development (~30 commits since
introduction), expected for new hardware enablement.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who is affected?
All users with GFX 12.1 AMD GPUs running v7.0.y kernels.

### Step 8.2: Trigger conditions
The bug triggers on **every GPU initialization** — boot, resume, GPU
reset. It's not a rare race or edge case.

### Step 8.3: Failure mode
Based on the earlier revert message: "data mismatch and slowness issues
with multiple HIP tests." Data mismatch is effectively **data
corruption** in GPU compute workloads. Severity: **HIGH** (data
corruption + performance degradation).

### Step 8.4: Risk-Benefit
- **Benefit:** HIGH — fixes data corruption and performance issues for
  all GFX 12.1 users on every GPU init
- **Risk:** VERY LOW — pure deletion of 19 lines, reverts to known-good
  previous behavior
- **Ratio:** Strongly favors backporting

## PHASE 9: FINAL SYNTHESIS

### Evidence FOR backporting:
- Fixes real bug: data mismatch (corruption) and slowness in GPU compute
  workloads
- Pure code removal (19 lines deleted, 0 added) — zero regression risk
- Reviewed by the original feature author (Mukul Joshi)
- Signed off by AMD GPU maintainer (Alex Deucher)
- The buggy code IS in v7.0 stable tree
- Triggers on every GPU initialization (not a rare edge case)
- History shows this feature was already reverted once before for the
  same class of issues

### Evidence AGAINST backporting:
- Terse commit message doesn't detail the specific bug
- Only applies to v7.0.y (new hardware)
- No Fixes: tag or explicit stable nomination

### Stable Rules Checklist:
1. Obviously correct and tested? **YES** — pure deletion, reviewed by
   feature author
2. Fixes a real bug? **YES** — data mismatch/corruption and slowness
3. Important issue? **YES** — data corruption severity
4. Small and contained? **YES** — 19 lines in one file
5. No new features or APIs? **YES** — only removes code
6. Can apply to stable? **YES** — applies cleanly to v7.0

## Verification

- [Phase 1] Parsed tags: Reviewed-by Mukul Joshi, Signed-off-by Alex
  Deucher (maintainer)
- [Phase 2] Diff analysis: 19 lines removed, 0 added. Function
  `gfx_v12_1_xcc_setup_tcp_thrashing_ctrl` deleted, call removed from
  `gfx_v12_1_init_golden_registers`
- [Phase 3] git show a41d94a7bb962: confirmed original commit added
  retry thrashing, is in v7.0
- [Phase 3] git merge-base --is-ancestor a41d94a7bb962 v7.0: YES
- [Phase 3] git merge-base --is-ancestor 29756a7535fac v7.0: NO (not in
  v7.0 yet)
- [Phase 3] git show 127770bcfccc2: earlier revert described "data
  mismatch and slowness issues with multiple HIP tests"
- [Phase 3] git tag --contains a41d94a7bb962: confirmed in v7.0,
  v7.0-rc1 through rc7
- [Phase 4] b4 dig -c 29756a7535fac: no match found on lore
- [Phase 4] b4 dig -c a41d94a7bb962: no match found on lore
- [Phase 5] grep TCP_UTCL0_THRASHING: only in gfx_v12_1.c and register
  headers
- [Phase 6] git show v6.12/v6.13/v6.19: file does not exist in any prior
  stable tree
- [Phase 6] Verified v7.0 tree state: function exists at line 2632,
  called at line 2698, patch applies cleanly
- [Phase 8] Failure mode: data corruption (data mismatch) + performance
  degradation, severity HIGH
- UNVERIFIED: Exact nature of the "bug found" in the revert message (but
  corroborated by the earlier revert's more detailed description)

The fix is a minimal, zero-risk pure deletion that fixes data corruption
and performance issues on GFX 12.1 hardware. The buggy code exists in
v7.0 stable, and the patch applies cleanly.

**YES**

 drivers/gpu/drm/amd/amdgpu/gfx_v12_1.c | 19 -------------------
 1 file changed, 19 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v12_1.c b/drivers/gpu/drm/amd/amdgpu/gfx_v12_1.c
index eb9725ae1607a..812de881027b4 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v12_1.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v12_1.c
@@ -2629,24 +2629,6 @@ static void gfx_v12_1_xcc_disable_gpa_mode(struct amdgpu_device *adev,
 	WREG32_SOC15(GC, GET_INST(GC, xcc_id), regCPG_PSP_DEBUG, data);
 }
 
-static void gfx_v12_1_xcc_setup_tcp_thrashing_ctrl(struct amdgpu_device *adev,
-					 int xcc_id)
-{
-	uint32_t val;
-
-	/* Set the TCP UTCL0 register to enable atomics */
-	val = RREG32_SOC15(GC, GET_INST(GC, xcc_id),
-					regTCP_UTCL0_THRASHING_CTRL);
-	val = REG_SET_FIELD(val, TCP_UTCL0_THRASHING_CTRL, THRASHING_EN, 0x2);
-	val = REG_SET_FIELD(val, TCP_UTCL0_THRASHING_CTRL,
-					RETRY_FRAGMENT_THRESHOLD_UP_EN, 0x1);
-	val = REG_SET_FIELD(val, TCP_UTCL0_THRASHING_CTRL,
-					RETRY_FRAGMENT_THRESHOLD_DOWN_EN, 0x1);
-
-	WREG32_SOC15(GC, GET_INST(GC, xcc_id),
-					regTCP_UTCL0_THRASHING_CTRL, val);
-}
-
 static void gfx_v12_1_xcc_enable_atomics(struct amdgpu_device *adev,
 					 int xcc_id)
 {
@@ -2695,7 +2677,6 @@ static void gfx_v12_1_init_golden_registers(struct amdgpu_device *adev)
 	for (i = 0; i < NUM_XCC(adev->gfx.xcc_mask); i++) {
 		gfx_v12_1_xcc_disable_burst(adev, i);
 		gfx_v12_1_xcc_enable_atomics(adev, i);
-		gfx_v12_1_xcc_setup_tcp_thrashing_ctrl(adev, i);
 		gfx_v12_1_xcc_disable_early_write_ack(adev, i);
 		gfx_v12_1_xcc_disable_tcp_spill_cache(adev, i);
 	}
-- 
2.53.0

[PATCH AUTOSEL 7.0] drm/amd/pm: Avoid overflow when sorting pp_feature list

[Sasha Levin]

From: Asad Kamal <asad.kamal@amd.com>

[ Upstream commit 8e8f6bda8a84f41c4002bca44ac89a5b3f8c7df2 ]

pp_features sorting uses int8_t sort_feature[] to store driver
feature enum indices. On newer ASICs the enum index can exceed 127,
causing signed overflow and silently dropping entries from the output.
Switch the array to int16_t so all enum indices are preserved.

Signed-off-by: Asad Kamal <asad.kamal@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a complete analysis. Let me
compile the full walkthrough.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem:** `drm/amd/pm` (AMD GPU power management)
- **Action verb:** "Avoid" (preventing a bug)
- **Summary:** Avoid integer overflow in `sort_feature[]` array when
  enum indices exceed `int8_t` max (127)

### Step 1.2: Tags
- `Signed-off-by: Asad Kamal <asad.kamal@amd.com>` - AMD employee,
  author
- `Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>` - AMD GPU PM subsystem
  reviewer
- `Signed-off-by: Alex Deucher <alexander.deucher@amd.com>` - AMD DRM
  maintainer
- No Fixes: tag, no Cc: stable, no Reported-by (expected for autosel
  candidates)

### Step 1.3: Commit Body
Bug: `int8_t sort_feature[]` stores enum indices that can exceed 127 on
newer ASICs. Signed overflow wraps values to negative, and the
subsequent `< 0` check silently drops those entries from the sysfs
output. Fix: widen to `int16_t`.

### Step 1.4: Hidden Bug Fix Detection
This is explicitly described as an overflow fix. Not hidden.

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- 1 file changed: `drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c`
- 1 line added, 1 line removed
- Function modified: `smu_cmn_get_pp_feature_mask()`

### Step 2.2: Code Flow
**Before:** `int8_t sort_feature[MAX(SMU_FEATURE_COUNT,
SMU_FEATURE_MAX)]` - can hold values -128 to 127.
**After:** `int16_t sort_feature[MAX(SMU_FEATURE_COUNT,
SMU_FEATURE_MAX)]` - can hold values -32768 to 32767.

The array is initialized to `-1` via `memset(sort_feature, -1,
sizeof(...))`, then populated with enum index `i` (0 to
`SMU_FEATURE_COUNT-1`). Entries remaining `-1` are skipped via the `< 0`
check. With `int8_t`, any `i >= 128` overflows to a negative value,
falsely triggering the skip.

### Step 2.3: Bug Mechanism
**Integer overflow / type bug.** `SMU_FEATURE_COUNT = 135` (verified by
counting enum entries). Indices 128-134 (7 features: `APT_SQ_THROTTLE`,
`APT_PF_DCS`, `GFX_EDC_XVMIN`, `GFX_DIDT_XVMIN`, `FAN_ABNORMAL`, `PIT`,
`HROM_EN`) overflow `int8_t`, wrapping to negative values and being
silently dropped.

### Step 2.4: Fix Quality
- Obviously correct: widening the type eliminates the overflow
- `memset(-1)` still works correctly: fills all bytes with `0xFF`,
  making each `int16_t` element `0xFFFF = -1` in two's complement
  (confirmed by the author in review discussion and correct by C
  standard)
- No regression risk: the type widening is strictly safe; no logic
  changes
- Minimal and surgical: 1-line change

## PHASE 3: GIT HISTORY

### Step 3.1: Blame
The `int8_t` type was introduced in commit `6f73d6762694c` ("drm/amd/pm:
optimize the interface for dpm feature status query", dated 2022-05-25,
by Evan Quan). Originally (commit `7dbf78051f75f1`, 2020), the array was
`uint32_t sort_feature[SMU_FEATURE_COUNT]` with no overflow possibility.
The refactoring in 6f73d6762694c downsized the type to `int8_t` (using
`-1` as sentinel).

### Step 3.2: Fixes: tag
No Fixes: tag present. The logical "Fixes:" would be `6f73d6762694c`
(introduced `int8_t`) + `25d48f2eb0af1` (pushed enum count past 127).

### Step 3.3: Related Changes
Recent changes to `smu_cmn.c` include significant refactoring of feature
mask handling (`7b88453a476c9` etc.), but none address this specific
overflow.

### Step 3.4: Author
Asad Kamal is an AMD employee who regularly contributes to `drm/amd/pm`.
Multiple recent commits in the subsystem.

### Step 3.5: Dependencies
No dependencies. The fix is self-contained.

## PHASE 4: MAILING LIST DISCUSSION

### Step 4.1: Original Submission
Found via `b4 dig -c 8e8f6bda8a84f`:
https://patch.msgid.link/20260302061242.3062232-1-asad.kamal@amd.com

### Step 4.2: Review Discussion
- **Lijo Lazar** (AMD reviewer): Gave `Reviewed-by` immediately
- **Kevin Wang** raised a concern about `memset(-1)` correctness with
  `int16_t` — asking whether it would correctly initialize all elements
  to `-1`
- **Asad Kamal** correctly explained: "memset fills all bytes with 0xFF.
  For int16_t, that becomes 0xFFFF, which is -1 in two's complement."
- **Kevin Wang** accepted the explanation: "Based on private
  discussions, please continue to submit the code."
- No NAKs, no concerns about the fix itself, only a clarification
  question that was satisfactorily resolved.

### Step 4.3-4.5: No external bug reports. No stable-specific discussion
found.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.2: Call Chain
`smu_cmn_get_pp_feature_mask()` is called via sysfs: user reads
`pp_features` -> `amdgpu_pm.c:amdgpu_dpm_get_ppfeature_status()` ->
`smu_sys_get_pp_feature_mask()` -> `smu_cmn_get_pp_feature_mask()`. Used
by **17 different GPU backends** (verified: SMU v11, v12, v13, v14, v15
variants).

### Step 5.4: User Reachability
Directly reachable from userspace via sysfs read. Any user or monitoring
tool reading GPU feature status triggers this code.

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable Trees
- `int8_t` introduced in `6f73d6762694c` (v5.19/v6.0 era)
- Overflow-triggering features added in `25d48f2eb0af1` (v6.12)
- **The overflow is triggerable in v6.12+ stable trees** where both the
  `int8_t` type and the >127 enum count coexist
- For older stable trees (6.6.y, 6.1.y), SMU_FEATURE_COUNT is still <
  128, so no overflow yet — but future backported features could trigger
  it

### Step 6.2: Backport Difficulty
Clean apply expected — the change is a single-line type change with no
context dependencies.

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem
- **drm/amd/pm** — AMD GPU power management, IMPORTANT criticality
- Affects all users with AMD GPUs using swSMU (modern AMD GPUs: RDNA2+,
  CDNA)

### Step 7.2: Activity
Very actively developed — many recent commits.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
All users with AMD GPUs running SMU v14.0.2/3 or newer (Radeon RX 8000
series and similar), or any ASIC whose feature mapping exceeds index
127.

### Step 8.2: Trigger Conditions
- **Trigger:** Any read of `pp_features` sysfs node
- **Frequency:** Common — monitoring tools, manual inspection, power
  management tools read this
- **Unprivileged:** Yes, sysfs readable by any user

### Step 8.3: Severity
- **MEDIUM:** Incorrect/incomplete sysfs output. Not a crash or security
  issue, but features are silently dropped, making power management
  monitoring unreliable.

### Step 8.4: Risk-Benefit
- **Benefit:** Fixes incorrect sysfs output for AMD GPU users; prevents
  silent data loss in feature reporting
- **Risk:** Extremely low — 1-line type change, no logic modification,
  correctness of `memset(-1)` with `int16_t` verified in review and
  mathematically sound
- **Stack increase:** `sort_feature` grows from 128 bytes
  (`int8_t[128]`) to 256 bytes (`int16_t[128]`); negligible for a stack-
  allocated array

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary
**FOR backporting:**
- Fixes a real, verifiable integer overflow bug
- SMU_FEATURE_COUNT = 135 > 127, confirmed to overflow `int8_t`
- 7 power management features silently dropped from sysfs output
- 1-line fix, obviously correct, minimal risk
- Reviewed by AMD engineer, no objections after clarification
- Used by 17 GPU backends across all modern AMD GPUs
- Signed off by Alex Deucher (AMD DRM maintainer)

**AGAINST backporting:**
- Not a crash or security issue (incorrect output only)
- Only affects v6.12+ trees where enum count exceeds 127
- No Fixes: tag or Cc: stable

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** YES — trivial type widening,
   reviewed
2. **Fixes a real bug?** YES — integer overflow causing features to be
   silently dropped
3. **Important issue?** MEDIUM — not crash/security, but correctness bug
   in user-visible output
4. **Small and contained?** YES — 1 line, 1 file
5. **No new features or APIs?** Correct — no new features
6. **Can apply to stable?** YES — clean apply expected

### Step 9.3: Exception Categories
None applicable — this is a standard bug fix.

### Step 9.4: Decision
This is a clean, minimal, well-reviewed bug fix for a verifiable integer
overflow that causes incorrect user-visible behavior on modern AMD GPUs.
It meets all stable criteria.

## Verification

- [Phase 1] Parsed tags: Reviewed-by Lijo Lazar, SOB from Alex Deucher
  (AMD maintainer)
- [Phase 2] Diff analysis: 1 line changed, `int8_t` -> `int16_t` in
  `smu_cmn_get_pp_feature_mask()`
- [Phase 2] Verified SMU_FEATURE_COUNT = 135 by counting enum entries in
  `smu_types.h` — 7 features exceed index 127
- [Phase 3] git blame: `int8_t` introduced in `6f73d6762694c`
  (v5.19/v6.0 era, Evan Quan, 2022)
- [Phase 3] Overflow-triggering features added in `25d48f2eb0af1`
  (v6.12, 2024-09-10)
- [Phase 3] Original type was `uint32_t` in `7dbf78051f75f1` (2020) — no
  overflow possible
- [Phase 4] b4 dig -c found submission:
  https://patch.msgid.link/20260302061242.3062232-1-asad.kamal@amd.com
- [Phase 4] b4 dig -w: AMD team members CC'd (lijo.lazar, hawking.zhang,
  le.ma, alexander.deucher, kevinyang.wang)
- [Phase 4] Review discussion decoded from base64: Kevin Wang raised
  memset concern, Asad explained correctly, Kevin approved
- [Phase 5] Traced call chain: sysfs read ->
  `amdgpu_dpm_get_ppfeature_status()` -> `smu_sys_get_pp_feature_mask()`
  -> target function
- [Phase 5] Verified 17 GPU backends use this function (SMU v11, v12,
  v13, v14, v15)
- [Phase 6] Bug triggerable in v6.12+ (both int8_t type and >127 enum
  present)
- [Phase 8] Severity: MEDIUM (incorrect sysfs output, not
  crash/security)
- [Phase 8] Risk: Very low (1-line type change, no logic change, stack
  grows by 128 bytes)

**YES**

 drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c b/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
index 6fd50c2fd20e0..97ed66cb47472 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
@@ -880,7 +880,7 @@ static const char *smu_get_feature_name(struct smu_context *smu,
 size_t smu_cmn_get_pp_feature_mask(struct smu_context *smu,
 				   char *buf)
 {
-	int8_t sort_feature[MAX(SMU_FEATURE_COUNT, SMU_FEATURE_MAX)];
+	int16_t sort_feature[MAX(SMU_FEATURE_COUNT, SMU_FEATURE_MAX)];
 	struct smu_feature_bits feature_mask;
 	uint32_t features[2];
 	int i, feature_index;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.19] drm/amd/display: Fix number of opp

[Sasha Levin]

From: Austin Zheng <Austin.Zheng@amd.com>

[ Upstream commit 2c5f15ee2c760514c5be0f02cf9c9f1ff68b9ac8 ]

[Why/How]
Patch number of opp based on IP caps

Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Austin Zheng <Austin.Zheng@amd.com>
Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a comprehensive analysis. Let
me compile the full report.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `drm/amd/display`
- Action verb: "Fix"
- Summary: Fix the number of OPP (Output Pixel Processors) patching from
  IP caps.

Record: [drm/amd/display] [fix] [Ensures max_num_opp is patched from IP
capabilities]

**Step 1.2: Tags**
- Reviewed-by: Dillon Varone (AMD display team member)
- Signed-off-by: Austin Zheng (author), Chuanyu Tseng (series submitter)
- Tested-by: Dan Wheeler (AMD's display QA)
- Signed-off-by: Alex Deucher (AMD display maintainer)
- No Fixes: tag (expected for autosel candidates)
- No Cc: stable (expected)

Record: Reviewed, tested, and signed off by the AMD display team. No
syzbot or external reports.

**Step 1.3: Body Text**
- "[Why/How] Patch number of opp based on IP caps"
- Terse message typical of AMD display DML patches. Indicates the OPP
  count should come from IP capabilities (hardware-specific) rather than
  remaining at the compile-time default.

Record: Bug is that `max_num_opp` was not being patched from hardware IP
caps, leaving it at a static default regardless of actual hardware.

**Step 1.4: Hidden Bug Fix Detection**
This is explicitly labeled "Fix" and adds a missing field assignment
that was omitted when OPP validation was introduced.

Record: This is a direct bug fix for a missing field patching, not a
hidden fix.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `dml2_core_dcn4.c`
- +1 line added
- Function modified: `patch_ip_params_with_ip_caps()`
- Scope: Single-file, surgical 1-line fix

**Step 2.2: Code Flow Change**
The single line added:

```c
ip_params->max_num_opp = ip_caps->otg_count;
```

BEFORE: `patch_ip_params_with_ip_caps()` copies all IP capability fields
to IP params EXCEPT `max_num_opp`. The `max_num_opp` remains at the
compile-time default from `core_dcn4_ip_caps_base` (hardcoded to 4).

AFTER: `max_num_opp` is correctly patched from `ip_caps->otg_count`,
matching the actual hardware's OTG count.

**Step 2.3: Bug Mechanism**
This is a **logic/correctness fix** - an omission bug. Commit
`610cf76e9453b` ("Add opp count validation to dml2.1") added OPP count
validation checks in `dml2_core_dcn4_calcs.c` that read
`mode_lib->ip.max_num_opp`, but the function that patches IP params from
IP caps (`patch_ip_params_with_ip_caps`) was not updated to copy
`max_num_opp`. The validation uses a stale default value instead of the
actual hardware capability.

The validation code at lines 8588 checks:
```c
if (mode_lib->ms.TotalNumberOfActiveOPP > (unsigned
int)mode_lib->ip.max_num_opp)
    mode_lib->ms.support.TotalAvailablePipesSupport = false;
```

If `max_num_opp` is wrong, display modes may be incorrectly accepted or
rejected.

**Step 2.4: Fix Quality**
- Obviously correct: follows the exact same pattern as ALL other fields
  in the function
- Minimal/surgical: 1 line
- Regression risk: effectively zero - it only adds missing
  initialization
- No red flags

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
The `patch_ip_params_with_ip_caps` function was introduced by commit
`70839da636050` (Aurabindo Pillai, 2024-04-19, "Add new DCN401
sources"). The function was created without a `max_num_opp` line because
at that time there was no `max_num_opp` field or OPP validation.

**Step 3.2: Fixes Target**
The commit that introduced the bug is `610cf76e9453b` ("Add opp count
validation to dml2.1", by Dmytro Laktyushkin, v6.19). That commit:
- Added `max_num_opp = 4` to `core_dcn4_ip_caps_base` static struct
- Added `max_num_opp` field to `dml2_core_ip_params`
- Added OPP validation in `dml2_core_dcn4_calcs.c`
- BUT did NOT add `max_num_opp` patching to
  `patch_ip_params_with_ip_caps()`

Record: The bug was introduced in v6.19. It exists in v6.19 and v7.0.

**Step 3.3: File History**
Only one commit in the 7.0 tree modified this specific file (the rename
from dml2/ to dml2_0/). The original code has had many "reintegration"
commits prior to v7.0.

**Step 3.4: Author**
Austin Zheng is a regular AMD display team contributor. Other commits
include DML-related fixes and data type corrections.

**Step 3.5: Dependencies**
The fix depends on commit `610cf76e9453b` ("Add opp count validation")
being present. Verified:
- v6.19: Has this prerequisite (confirmed via `git show`)
- v6.18 and older: Do NOT have this prerequisite
- v6.12 LTS: Does NOT have this prerequisite

## PHASE 4: MAILING LIST RESEARCH

Found the original submission: "[PATCH v2 0/9] DC Patches March 10,
2026" on amd-gfx mailing list. The fix was patch 7 of 9 in a v2 series
submitted by Chuanyu Tseng. The series was merged via the normal AMD
display patch flow. It was NOT part of drm-fixes-7.0 (the -fixes pull
only had different urgent fixes).

No NAKs or objections found. No explicit stable nomination.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Key function:** `patch_ip_params_with_ip_caps()` - called from
`core_dcn4_initialize()` during DML2 core initialization.

**Impact path:** `dml21_populate_dml_init_params()` ->
`core_dcn4_initialize()` -> `patch_ip_params_with_ip_caps()`. This runs
during display mode validation for every display configuration change on
DCN4+ hardware.

**Consumer of `max_num_opp`:** Used in `CalculateODMMode()` and the main
mode support validation loop in `dml2_core_dcn4_calcs.c` (lines 8421,
8442, 8588) to validate that active OPP count doesn't exceed hardware
capability.

## PHASE 6: STABLE TREE ANALYSIS

**Bug existence by tree:**
- v7.0: BUG EXISTS (verified - `max_num_opp` in struct at line 31,
  validation in calcs, but missing patching)
- v6.19: BUG EXISTS (verified - same state as 7.0, file at dml2_0 path)
- v6.18: Bug does NOT exist (no `max_num_opp` field or validation)
- v6.12 LTS: Bug does NOT exist
- v6.6 LTS, v6.1 LTS: Bug does NOT exist

**Backport complexity:** For 7.0.y: should apply cleanly. For 6.19.y:
path may need adjustment (file is at `dml2_0/` in v6.19 already, so it
may apply cleanly).

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

- Subsystem: drm/amd/display - DML2 (Display Mode Library) for DCN4+
- Criticality: IMPORTANT - affects AMD GPU display output for newer
  hardware
- The DML2.1 code is actively developed with frequent "reintegration"
  commits

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Who is affected:** Users of AMD DCN4+ GPUs where the actual OPP/OTG
count differs from the compile-time default of 4 (e.g., harvested
silicon, different SKUs).

**Trigger conditions:** Any display mode validation on affected
hardware. This runs during every display configuration change (mode set,
multi-monitor setup, etc.).

**Failure mode:** Incorrect DML mode validation:
- If real OPP count < 4: modes could be accepted that the hardware can't
  support (display corruption or failure)
- If real OPP count > 4: modes could be incorrectly rejected (user can't
  use supported display configurations)
- Severity: MEDIUM-HIGH for affected hardware

**Risk-Benefit:**
- Benefit: Correct mode validation on all DCN4 hardware variants
- Risk: VERY LOW - 1 line, follows established pattern, no behavioral
  change for hardware where count == 4

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Fixes a real bug (missing field initialization) with concrete
  consequences
- Trivially correct (1 line, follows exact pattern of all other fields)
- Reviewed and tested by AMD display team
- Affects display functionality on AMD DCN4 hardware
- Zero regression risk for hardware where OPP count == 4 (most current
  hardware)

**Evidence AGAINST backporting:**
- Only affects hardware with non-default OPP counts (subset of DCN4
  ASICs)
- Commit message is terse with minimal detail
- Not submitted via -fixes flow (went through normal DC patches)
- Only applicable to trees containing v6.19+ (610cf76e9453b)

**Stable rules checklist:**
1. Obviously correct? YES - exact pattern match with all other fields
2. Fixes real bug? YES - incorrect DML mode validation
3. Important issue? YES for affected hardware (display functionality)
4. Small and contained? YES - 1 line
5. No new features? YES
6. Applies to stable? YES for 7.0.y and 6.19.y

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Dillon Varone, Tested-by Dan
  Wheeler, author Austin Zheng, maintainer Alex Deucher
- [Phase 2] Diff analysis: 1 line added to
  `patch_ip_params_with_ip_caps()`, adds missing `max_num_opp` field
  patching
- [Phase 3] git blame: `patch_ip_params_with_ip_caps()` introduced in
  70839da636050 (v6.12 era) without `max_num_opp`
- [Phase 3] git show 610cf76e9453b: confirmed this commit added opp
  validation but missed updating `patch_ip_params_with_ip_caps()` - this
  is the root cause
- [Phase 3] git show v6.19 file: confirmed `max_num_opp = 4` in struct
  AND validation in calcs, BUT missing patching - bug exists in v6.19
- [Phase 3] git show v6.18 file: confirmed no `max_num_opp` at all - bug
  does NOT exist pre-6.19
- [Phase 3] git show v6.12 file: confirmed no `max_num_opp` at all
- [Phase 4] Found original submission: "[PATCH v2 0/9] DC Patches March
  10, 2026" on amd-gfx mailing list
- [Phase 4] No NAKs or concerns found in mailing list
- [Phase 5] `max_num_opp` is consumed at lines 8421, 8442, 8588 of
  dml2_core_dcn4_calcs.c for display mode validation
- [Phase 5] `patch_ip_params_with_ip_caps()` called from
  `core_dcn4_initialize()`, which runs during every DML initialization
- [Phase 6] Bug exists in v6.19 and v7.0 only - confirmed by checking
  file contents at each tagged version
- [Phase 8] Failure mode: incorrect mode validation leading to display
  issues, severity MEDIUM-HIGH for affected hardware
- UNVERIFIED: Exact set of AMD ASICs where OPP count differs from
  default 4 could not be determined (dcn42 bounding box header not found
  in tree)

The fix is a trivially correct 1-line addition that patches a missing
field from the hardware IP capabilities, fixing incorrect DML mode
validation on AMD DCN4 hardware where the OPP count may differ from the
compile-time default.

**YES**

 .../amd/display/dc/dml2_0/dml21/src/dml2_core/dml2_core_dcn4.c   | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dml2_0/dml21/src/dml2_core/dml2_core_dcn4.c b/drivers/gpu/drm/amd/display/dc/dml2_0/dml21/src/dml2_core/dml2_core_dcn4.c
index eba948e187c11..93d479083acde 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2_0/dml21/src/dml2_core/dml2_core_dcn4.c
+++ b/drivers/gpu/drm/amd/display/dc/dml2_0/dml21/src/dml2_core/dml2_core_dcn4.c
@@ -107,6 +107,7 @@ static void patch_ip_params_with_ip_caps(struct dml2_core_ip_params *ip_params,
 {
 	ip_params->max_num_dpp = ip_caps->pipe_count;
 	ip_params->max_num_otg = ip_caps->otg_count;
+	ip_params->max_num_opp = ip_caps->otg_count;
 	ip_params->num_dsc = ip_caps->num_dsc;
 	ip_params->max_num_dp2p0_streams = ip_caps->max_num_dp2p0_streams;
 	ip_params->max_num_dp2p0_outputs = ip_caps->max_num_dp2p0_outputs;
-- 
2.53.0

[PATCH AUTOSEL 7.0] drm/amd/display: Fix HWSS v3 fast path determination

[Sasha Levin]

From: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>

[ Upstream commit d3e79f333d90f6d3d268c3b073cf3afc0b019036 ]

[WHY]
We're checking surface and stream updates after they've been applied to
their respective states within `update_planes_and_stream_state`.

Medium updates under the HWSS V3 fast path that are not supported or
tested are getting implicitly if they don't trigger a DML validation
and getting updated in place on the dc->current_state context.

[HOW]
Fix this issue by moving up the fast path determination check prior
to `update_planes_and_stream_state`. This is how the V2 path works
and how the V3 path used to work prior to the refactors in this area.

Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for the complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
Record: **[drm/amd/display]** **[Fix]** Fix HWSS v3 fast path
determination — corrects the ordering of fast path evaluation in the V3
update flow.

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Reviewed-by:** Dillon Varone <dillon.varone@amd.com> — an AMD
  display engineer reviewed this
- **Signed-off-by:** Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> —
  the author, an AMD display subsystem developer
- **Signed-off-by:** Alex Hung <alex.hung@amd.com> — AMD display
  committer
- **Tested-by:** Dan Wheeler <daniel.wheeler@amd.com> — AMD QA testing
- **Signed-off-by:** Alex Deucher <alexander.deucher@amd.com> — AMD GPU
  maintainer
- No Fixes: tag (expected for autosel)
- No Cc: stable (expected for autosel)
- No Reported-by (likely found internally during code review/testing)

Record: Multiple AMD engineers reviewed/tested/signed off. Standard AMD
display commit flow through maintainer tree.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit clearly describes:
- **Bug**: Surface and stream updates are checked AFTER they've been
  applied to state within `update_planes_and_stream_state`. This means
  `fast_update_only` sees already-modified state, causing incorrect fast
  path determination.
- **Symptom**: Medium updates that should go through the full commit
  path are incorrectly routed to the fast path. These "are not supported
  or tested" updates get "implicitly" applied "in place on the
  dc->current_state context."
- **Fix**: Move the fast path determination check BEFORE
  `update_planes_and_stream_state`, matching V2 behavior and original V3
  behavior prior to refactoring.

Record: Bug = incorrect fast path determination due to wrong ordering.
Failure mode = untested update types being applied via fast path,
leading to potential display corruption.

### Step 1.4: DETECT HIDDEN BUG FIXES
This is explicitly marked as "Fix" and the commit message clearly
explains the bug mechanism. Not a hidden bug fix.

Record: Explicitly a bug fix.

---

## PHASE 2: DIFF ANALYSIS — LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
- **File:** `drivers/gpu/drm/amd/display/dc/core/dc.c`
- **Functions modified:** `update_planes_and_stream_prepare_v3()`
- **Net change:** ~15 lines of code moved from one location to another
  within the same function; removed TODO comments; net line change is
  approximately -2 lines.
- **Scope:** Single-file surgical fix within a single function.

Record: 1 file, 1 function, net ~-2 lines. Single-file surgical fix.

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE

**Before:** After `dc_exit_ips_for_hw_access()`, immediately calls
`update_planes_and_stream_state()` which modifies surface/stream state.
THEN, inside the `new_context == current_state` branch, performs
`populate_fast_updates()` and `fast_update_only()` check.

**After:** After `dc_exit_ips_for_hw_access()`, FIRST calls
`populate_fast_updates()` and `fast_update_only()` on the unmodified
state. THEN calls `update_planes_and_stream_state()`. The pre-computed
`is_hwss_fast_path_only` result is used later.

### Step 2.3: IDENTIFY THE BUG MECHANISM
This is a **logic/correctness fix**. The `full_update_required()`
function (called via `fast_update_only()`) compares update values
against current surface/stream state (e.g.,
`srf_updates[i].hdr_mult.value !=
srf_updates->surface->hdr_mult.value`). After
`update_planes_and_stream_state` copies the update into the surface
state (`copy_surface_update_to_plane`), these comparisons see the
already-updated values, causing the function to incorrectly return
`false` (no full update needed) when it should return `true`.

Record: Logic bug — wrong evaluation order causes
`full_update_required()` to compare update values against already-
modified state, leading to false negatives for full-update detection.

### Step 2.4: ASSESS THE FIX QUALITY
- **Obviously correct:** Yes — moving the check before state
  modification is the logical correct order, and matches V2's behavior.
- **Minimal/surgical:** Yes — only moves existing code within one
  function.
- **Regression risk:** Very low — the check now runs on pre-modification
  state, which is how V2 works and how V3 used to work before the
  refactoring.
- **No red flags:** Single function, single file, no API changes.

Record: Fix is obviously correct, minimal, and low regression risk.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
`git blame` shows the buggy code was introduced by commit
`d38ec099aa6fb7` ("drm/amd/display: Split update_planes_and_stream_v3
into parts (V2)") by Dominik Kaszewski, dated 2025-10-31. This commit
was a refactoring that split the V3 update flow into
prepare/execute/cleanup stages but accidentally placed the fast path
determination after state modification.

Record: Buggy code introduced by d38ec099aa6fb7 (2025-10-31), first
appeared in v7.0-rc1.

### Step 3.2: FOLLOW THE FIXES: TAG
No Fixes: tag present (expected). But the blame clearly identifies
d38ec099aa6fb7 as the introducing commit.

Record: Introducing commit d38ec099aa6fb7 is present in v7.0-rc1 and
v7.0, not in any older stable tree.

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Commit `5ad5b0b7845c9` ("Fix and reenable
UPDATE_V3_FLOW_NEW_CONTEXT_MINIMAL") followed the introducing commit and
fixed other issues in the V3 flow but did NOT fix this ordering issue.
The fix under review is a standalone, independent fix.

Record: Related fix 5ad5b0b7845c9 exists but addresses a different V3
issue. This fix is standalone.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Nicholas Kazlauskas is a prolific AMD display developer and the reviewer
of the original refactoring commit. He clearly understands the subsystem
deeply and identified this ordering bug.

Record: Author is a key AMD display developer and subsystem expert.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
The fix has no external dependencies. It modifies code that exists in
v7.0 and applies to the `update_planes_and_stream_prepare_v3` function
as-is in the current tree.

Record: No dependencies. Self-contained fix.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1-4.5: MAILING LIST INVESTIGATION
`b4 dig` could not find the original patch submissions (both the fix and
the introducing commit) on lore.kernel.org. AMD display patches are
often submitted through internal tooling (amd-gfx list) and may not be
indexed by lore in the same way. Lore.kernel.org was also protected by
Anubis anti-bot measures.

Record: Could not find lore discussion. AMD display patches often flow
through internal AMD tooling.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: KEY FUNCTIONS
- `update_planes_and_stream_prepare_v3()` — the function being fixed
- `populate_fast_updates()` — populates fast update structure from
  surface/stream updates
- `fast_update_only()` → `full_update_required()` — determines if only
  fast updates exist (no full update needed)
- `update_planes_and_stream_state()` — applies updates to surface/stream
  state and determines update type

### Step 5.2: TRACE CALLERS
`update_planes_and_stream_prepare_v3` is called from
`dc_update_planes_and_stream_prepare` → called from
`dc_update_planes_and_stream` → called from `amdgpu_dm.c` (the main AMD
display manager path). This is the **primary display update path** for
all AMD GPU operations including mode setting, cursor updates,
pageflips, etc.

### Step 5.3-5.4: CALL CHAIN
The path is: userspace (DRM ioctl) → `amdgpu_dm` →
`dc_update_planes_and_stream` → `dc_update_planes_and_stream_prepare` →
`update_planes_and_stream_prepare_v3`. This is directly reachable from
userspace display operations.

### Step 5.5: SIMILAR PATTERNS
The V2 path (`update_planes_and_stream_v2`, line 5231-5233) correctly
performs `populate_fast_updates` and `fast_update_only` BEFORE
`update_planes_and_stream_state`. The fix aligns V3 with V2's correct
ordering.

Record: Main display update path, reachable from userspace. V2 already
has the correct ordering.

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
The buggy code was introduced by d38ec099aa6fb7, first tagged in
v7.0-rc1. It does NOT exist in any stable tree older than 7.0.y. Only
the 7.0.y stable tree is affected.

Record: Bug only exists in 7.0.y.

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
The fix should apply cleanly to 7.0.y since the code was introduced in
v7.0-rc1 and there have been no significant refactors to this specific
code region since then (only the `5ad5b0b7845c9` commit touched a
different part of the same function).

Record: Expected clean apply to 7.0.y.

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE
No related fixes for this specific issue found.

Record: No existing fix for this issue in stable.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
**Subsystem:** `drivers/gpu/drm/amd/display` — AMD GPU display driver
**Criticality:** IMPORTANT — affects all users with AMD RDNA 3 and RDNA
4 GPUs (very popular consumer hardware: RX 7000 series and RX 9000
series).

### Step 7.2: SUBSYSTEM ACTIVITY
The AMD display subsystem is extremely active with dozens of commits per
release cycle.

Record: Very active subsystem, widely-used hardware.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
All users with AMD DCN 3.2 (RDNA 3), DCN 3.21 (RDNA 3 refresh), or DCN
4.01+ (RDNA 4) GPUs running kernel 7.0.y. These are very popular
consumer GPUs.

Record: Driver-specific but affects millions of AMD GPU users.

### Step 8.2: TRIGGER CONDITIONS
The bug triggers whenever a medium update (e.g., HDR metadata, scaling,
color space change) is submitted through the display update path AND the
update values match after state application. This can happen during
normal desktop operations, video playback, HDR content switching, etc.

Record: Triggered during normal display operations. Common trigger.

### Step 8.3: FAILURE MODE SEVERITY
When the bug triggers:
- Display updates that require full hardware programming go through the
  fast path instead
- This can cause **display corruption** (visual artifacts, incorrect
  rendering)
- Updates applied "in place on dc->current_state" without proper
  validation
- The commit message says these code paths "are not supported or tested"

Record: Display corruption. Severity: **HIGH** (visual artifacts,
incorrect rendering, untested code paths).

### Step 8.4: RISK-BENEFIT RATIO
- **BENEFIT:** Prevents display corruption on popular AMD hardware
  during common display operations. HIGH benefit.
- **RISK:** Very low — the fix moves ~15 lines of code within a single
  function, matching proven V2 behavior. The fix was reviewed and tested
  by AMD engineers.

Record: High benefit, very low risk. Clear positive ratio.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Fixes a real display corruption bug on widely-used AMD hardware (RDNA
  3 & RDNA 4)
- Small, surgical fix (single function, ~15 lines moved)
- Obviously correct (matches V2 path behavior and pre-refactoring V3
  behavior)
- Reviewed by AMD display engineer (Dillon Varone)
- Tested by AMD QA (Dan Wheeler)
- Authored by AMD display subsystem expert (Nicholas Kazlauskas)
- Signed off by AMD GPU maintainer (Alex Deucher)
- No external dependencies
- Should apply cleanly to 7.0.y

**AGAINST backporting:**
- Only affects 7.0.y (bug introduced in v7.0-rc1)
- No explicit user bug reports (likely caught internally)

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** — reviewed and tested by AMD,
   matches V2 behavior
2. Fixes a real bug? **YES** — incorrect fast path determination leading
   to display corruption
3. Important issue? **YES** — display corruption on popular hardware
4. Small and contained? **YES** — single function, single file, ~15
   lines
5. No new features or APIs? **YES** — pure fix
6. Can apply to stable trees? **YES** — should apply cleanly to 7.0.y

### Step 9.3: EXCEPTION CATEGORIES
Not applicable — this is a straightforward bug fix, not an exception
category.

### Step 9.4: DECISION
The evidence strongly supports backporting. This is a well-reviewed,
tested, small fix for a display corruption bug affecting popular AMD GPU
hardware on the main display update code path.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by (Dillon Varone), Tested-by (Dan
  Wheeler), SOBs from AMD maintainers
- [Phase 2] Diff analysis: ~15 lines of
  `populate_fast_updates`/`fast_update_only` moved before
  `update_planes_and_stream_state` in
  `update_planes_and_stream_prepare_v3()`
- [Phase 2] Confirmed `full_update_required()` compares
  `srf_updates[i].hdr_mult.value !=
  srf_updates->surface->hdr_mult.value` (line 5151-5152), which becomes
  false after `copy_surface_update_to_plane` (line 3592)
- [Phase 2] Confirmed `update_planes_and_stream_state` calls
  `copy_surface_update_to_plane` at line 3592 and
  `copy_stream_update_to_stream` at line 3556
- [Phase 3] git blame: buggy code introduced by d38ec099aa6fb7 (Dominik
  Kaszewski, 2025-10-31) — "Split update_planes_and_stream_v3 into parts
  (V2)"
- [Phase 3] git tag --contains: d38ec099aa6fb7 first in v7.0-rc1, so
  only 7.0.y affected
- [Phase 3] V2 path (line 5231-5233) does fast path check BEFORE
  `update_planes_and_stream_state` (line 5246) — confirmed correct
  ordering
- [Phase 3] Author Nicholas Kazlauskas has 10+ commits in dc.c, is the
  reviewer of the original refactoring commit
- [Phase 4] b4 dig: could not find original submission on lore (AMD
  patches often flow through internal tooling)
- [Phase 5] Call chain: userspace → amdgpu_dm →
  dc_update_planes_and_stream → dc_update_planes_and_stream_prepare →
  update_planes_and_stream_prepare_v3 — main display update path
- [Phase 5] V3 path enabled for DCN_VERSION_4_01+ || DCN_VERSION_3_2 ||
  DCN_VERSION_3_21 (line 7524) — RDNA 3 and RDNA 4
- [Phase 6] Bug only in 7.0.y (d38ec099aa6fb7 first in v7.0-rc1)
- [Phase 8] Failure mode: display corruption from untested fast path
  updates; severity HIGH
- UNVERIFIED: Could not access lore.kernel.org discussion due to anti-
  bot protection

**YES**

 drivers/gpu/drm/amd/display/dc/core/dc.c | 38 +++++++++++-------------
 1 file changed, 18 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 4c5ecbb97d5b0..47064e9bc08ad 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -7285,6 +7285,23 @@ static bool update_planes_and_stream_prepare_v3(
 	ASSERT(scratch->flow == UPDATE_V3_FLOW_INVALID);
 	dc_exit_ips_for_hw_access(scratch->dc);
 
+	/* HWSS path determination needs to be done prior to updating the surface and stream states. */
+	struct dc_fast_update fast_update[MAX_SURFACES] = { 0 };
+
+	populate_fast_updates(fast_update,
+			      scratch->surface_updates,
+			      scratch->surface_count,
+			      scratch->stream_update);
+
+	const bool is_hwss_fast_path_only =
+		fast_update_only(scratch->dc,
+				 fast_update,
+				 scratch->surface_updates,
+				 scratch->surface_count,
+				 scratch->stream_update,
+				 scratch->stream) &&
+		!scratch->dc->check_config.enable_legacy_fast_update;
+
 	if (!update_planes_and_stream_state(
 			scratch->dc,
 			scratch->surface_updates,
@@ -7300,26 +7317,7 @@ static bool update_planes_and_stream_prepare_v3(
 	if (scratch->new_context == scratch->dc->current_state) {
 		ASSERT(scratch->update_type < UPDATE_TYPE_FULL);
 
-		// TODO: Do we need this to be alive in execute?
-		struct dc_fast_update fast_update[MAX_SURFACES] = { 0 };
-
-		populate_fast_updates(
-				fast_update,
-				scratch->surface_updates,
-				scratch->surface_count,
-				scratch->stream_update
-		);
-		const bool fast = fast_update_only(
-				scratch->dc,
-				fast_update,
-				scratch->surface_updates,
-				scratch->surface_count,
-				scratch->stream_update,
-				scratch->stream
-		)
-		// TODO: Can this be used to skip `populate_fast_updates`?
-				&& !scratch->dc->check_config.enable_legacy_fast_update;
-		scratch->flow = fast
+		scratch->flow = is_hwss_fast_path_only
 				? UPDATE_V3_FLOW_NO_NEW_CONTEXT_CONTEXT_FAST
 				: UPDATE_V3_FLOW_NO_NEW_CONTEXT_CONTEXT_FULL;
 		return true;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] drm/amd/display: Remove invalid DPSTREAMCLK mask usage

[Sasha Levin]

From: Roman Li <Roman.Li@amd.com>

[ Upstream commit 8de2559ec172b04301d6e53c4f30388e40fad08c ]

[Why]
The invalid register field access causes ASSERT(mask != 0) to fire
in set_reg_field_values() during display enable.

WARNING: at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:100
set_reg_field_values.isra.0+0xcf/0xf0 [amdgpu]
Call Trace:
 <TASK>
generic_reg_update_ex+0x66/0x1d0 [amdgpu]
dccg401_set_dpstreamclk+0xed/0x350 [amdgpu]
dcn401_enable_stream+0x165/0x370 [amdgpu]
link_set_dpms_on+0x6e9/0xe90 [amdgpu]
dce110_apply_single_controller_ctx_to_hw+0x343/0x530 [amdgpu]
dce110_apply_ctx_to_hw+0x1f6/0x2d0 [amdgpu]
dc_commit_state_no_check+0x49a/0xe20 [amdgpu]
dc_commit_streams+0x354/0x570 [amdgpu]
amdgpu_dm_atomic_commit_tail+0x6f8/0x3fc0 [amdgpu]

DCN4.x hardware does not have DPSTREAMCLK_GATE_DISABLE and
DPSTREAMCLK_ROOT_GATE_DISABLE fields in DCCG_GATE_DISABLE_CNTL3.
These global fields only exist in DCN3.1.x hardware.

[How]
Remove the call that tries to update non-existent fields in CNTL3.
DCN4.x uses per-instance fields in CNTL5 instead,
which are already correctly programmed in the switch cases above.

Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Roman Li <Roman.Li@amd.com>
Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I now have all the evidence needed. Let me compile the complete
analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `drm/amd/display` (AMD Display Core for DCN401 / RDNA 4)
- Action verb: "Remove" (removing invalid code that causes an assertion
  failure)
- Summary: Removes register field access to non-existent mask fields on
  DCN4.x hardware

**Step 1.2: Tags**
- `Reviewed-by: Dillon Varone <dillon.varone@amd.com>` - AMD display
  engineer reviewed
- `Signed-off-by: Roman Li` (author), `Chuanyu Tseng`, `Alex Deucher`
  (AMD drm subsystem maintainer)
- No Fixes: tag (expected for manual review candidates)
- No Cc: stable (expected)

**Step 1.3: Commit Body**
The commit includes a full stack trace showing a WARNING triggered from
`ASSERT(mask != 0)` in `set_reg_field_values()` during display enable.
The path is: `amdgpu_dm_atomic_commit_tail -> dc_commit_streams -> ...
-> dccg401_set_dpstreamclk -> generic_reg_update_ex ->
set_reg_field_values`. The bug is that DCN4.x code tries to write
`DPSTREAMCLK_GATE_DISABLE` and `DPSTREAMCLK_ROOT_GATE_DISABLE` fields in
`DCCG_GATE_DISABLE_CNTL3`, but those global fields only exist in
DCN3.1.x hardware.

**Step 1.4: Hidden Bug Fix?**
This is explicitly a bug fix, not disguised. The WARNING/ASSERT fires on
every display enable path.

Record: Clear bug fix. WARNING/ASSERT fires on the normal display enable
path for all DCN4.x hardware.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Single file:
  `drivers/gpu/drm/amd/display/dc/dccg/dcn401/dcn401_dccg.c`
- 4 lines removed, 0 lines added
- Single function modified: `dccg401_enable_dpstreamclk`
- Classification: Single-file surgical fix

**Step 2.2: Code Flow Change**
Before: After the per-instance switch statement (which correctly
programs CNTL5), the function unconditionally tries to update
`DCCG_GATE_DISABLE_CNTL3` with `DPSTREAMCLK_GATE_DISABLE` and
`DPSTREAMCLK_ROOT_GATE_DISABLE`. Since these masks are 0, ASSERT fires.

After: The function ends after the per-instance switch cases, which
already correctly program the per-instance fields in CNTL5.

**Step 2.3: Bug Mechanism**
Category: Logic/correctness - writing to register fields that don't
exist on this hardware. The `FN()` macro expands to `(shift=0, mask=0)`
because `DCCG_MASK_SH_LIST_DCN401` in the header never initializes these
fields.

**Step 2.4: Fix Quality**
Absolutely minimal and obviously correct. The header file
`dcn401_dccg.h` lists all mask/shift entries for DCN401 and does NOT
include `DPSTREAMCLK_GATE_DISABLE` or `DPSTREAMCLK_ROOT_GATE_DISABLE`.
The per-instance equivalents in CNTL5 (e.g. `DPSTREAMCLK0_GATE_DISABLE`
through `DPSTREAMCLK3_GATE_DISABLE`) are already programmed in each
switch case. Zero regression risk.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
All buggy lines trace to commit `70839da636050` "drm/amd/display: Add
new DCN401 sources" by Aurabindo Pillai (2024-04-19). The DCN401 code
was copied from DCN31 where these global CNTL3 fields are valid. The bug
has been present since DCN401's introduction.

**Step 3.2: Fixes Tag**
No Fixes: tag present. However, the implicit target is `70839da636050`
which first appeared in v6.11-rc1.

**Step 3.3: File History**
Recent changes to the file are mostly refactoring/restructuring. No
related DPSTREAMCLK fixes were found.

**Step 3.4: Author**
Roman Li is an AMD display team member with multiple commits to
drm/amd/display. Alex Deucher is the AMD drm subsystem maintainer who
signed off.

**Step 3.5: Dependencies**
None. This is a standalone 4-line removal. No prerequisites needed.

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1-4.5:**
b4 dig did not find a lore thread (AMD often submits through internal
processes to drm-next). Web search also did not surface a specific lore
discussion. This is typical for AMD display driver commits which go
through Alex Deucher's drm-next tree.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions Modified**
`dccg401_enable_dpstreamclk` - called from `dccg401_set_dpstreamclk`

**Step 5.2: Callers**
The call chain from the stack trace:
- `amdgpu_dm_atomic_commit_tail` -> `dc_commit_streams` -> ... ->
  `dcn401_enable_stream` -> `dccg401_set_dpstreamclk` ->
  `dccg401_enable_dpstreamclk`

This is the **main display enable path** - triggered every time a
display mode is committed on RDNA 4 hardware (mode set, resume from
suspend, hotplug, etc.).

**Step 5.3-5.4: Call Chain**
The buggy path is reachable from userspace via any DRM atomic commit
that enables a display stream (e.g., `xrandr`, Wayland compositor, KMS
modesetting). This is the most common display operation.

**Step 5.5: Similar Patterns**
DCN31 (`dcn31_dccg.c`) correctly uses these fields because
`DCCG_MASK_SH_LIST_DCN31` includes them. The bug is specific to DCN401
which copied the DCN31 code but doesn't have these hardware fields.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable Trees**
DCN401 was introduced in v6.11. Active stable trees 6.11.y, 6.12.y, and
7.0.y all contain this buggy code. (6.6.y and earlier do not have
DCN401.)

**Step 6.2: Backport Complications**
The fix is a simple 4-line removal. The surrounding code is identical in
all stable trees that have DCN401. Expected clean apply.

**Step 6.3: No Related Fix in Stable**
No previous DPSTREAMCLK fix for DCN401 exists in any stable tree.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:** drm/amd/display - AMD GPU display driver. DCN401
corresponds to RDNA 4 (Radeon RX 9000 series), a current-generation
consumer/professional GPU.
Criticality: IMPORTANT - affects all RDNA 4 GPU owners using
DisplayPort.

**Step 7.2:** Active subsystem with frequent updates.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affected users: All AMD RDNA 4 GPU users with DisplayPort
displays.

**Step 8.2:** Trigger: Every display enable (mode set, resume, hotplug).
Very common. Occurs on the normal code path, not an error path.

**Step 8.3:** Failure mode: `WARNING` fires on every display enable.
Severity: HIGH
- Produces kernel log warnings on every mode set
- Systems with `panic_on_warn=1` will CRASH
- Even without panic_on_warn, the WARNING indicates potentially
  undefined register writes

**Step 8.4:** Risk-Benefit:
- BENEFIT: Very high - eliminates WARNING on every display operation for
  all RDNA 4 DP users
- RISK: Extremely low - 4 lines removed, removing code that accesses
  non-existent register fields; per-instance fields in CNTL5 are already
  correctly programmed

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Compilation**

FOR backporting:
- Fixes a real bug with a full stack trace in the commit message
- WARNING fires on the normal display enable path for ALL RDNA 4 DP
  users
- Systems with panic_on_warn will crash
- Fix is 4 lines of pure removal - minimally invasive
- Obviously correct: header confirms fields don't exist in DCN401 mask
  list
- Per-instance CNTL5 fields already handle the functionality correctly
- Reviewed by AMD display engineer (Dillon Varone)
- Signed off by AMD drm maintainer (Alex Deucher)
- Bug has existed since DCN401 introduction (v6.11)

AGAINST backporting:
- None identified

**Step 9.2: Stable Rules Checklist**
1. Obviously correct? YES - verified by mask/shift header analysis
2. Fixes a real bug? YES - WARNING on every display enable
3. Important? YES - affects all RDNA 4 DP users, crash with
   panic_on_warn
4. Small and contained? YES - 4 lines removed in 1 file
5. No new features? YES - pure removal of invalid code
6. Applies to stable? YES - DCN401 exists in 6.11+, code is identical

**Step 9.3: Exception Categories**
Not an exception category - this is a straightforward bug fix.

**Step 9.4: Decision**
Clear YES. This is a textbook stable candidate.

## Verification

- [Phase 1] Parsed tags: Reviewed-by from AMD display engineer, SOBs
  from author + AMD maintainer
- [Phase 2] Diff analysis: 4 lines removed from
  `dccg401_enable_dpstreamclk()`, removing invalid CNTL3 register field
  access
- [Phase 3] git blame: All buggy lines from commit 70839da636050 "Add
  new DCN401 sources" (2024-04-19), first in v6.11-rc1
- [Phase 3] git tag --contains: Confirmed DCN401 introduced in v6.11-rc1
- [Phase 5] Traced callers: `dccg401_set_dpstreamclk` ->
  `dccg401_enable_dpstreamclk` called from `dcn401_enable_stream` during
  every display enable
- [Phase 5] Verified mask list: `DCCG_MASK_SH_LIST_DCN401` in
  dcn401_dccg.h has per-instance DPSTREAMCLK[0-3] fields in CNTL5, but
  NO global DPSTREAMCLK_GATE_DISABLE/DPSTREAMCLK_ROOT_GATE_DISABLE in
  CNTL3
- [Phase 5] Verified assert: `dc_helper.c:100` has `ASSERT(mask != 0)`
  confirming the WARNING trigger
- [Phase 5] Verified DCN31 has the fields: `dcn31_dccg.h` lines 153-154
  include the global CNTL3 fields
- [Phase 6] dcn401_resource.c: Static const `dccg_mask` initialized with
  `DCCG_MASK_SH_LIST_DCN401(_MASK)` - confirmed fields are zero
- [Phase 6] DCN401 exists in stable trees v6.11+
- [Phase 4] b4 dig: No lore match found (typical for AMD drm-next
  submissions)
- UNVERIFIED: Exact lore discussion thread (b4 dig and web search
  failed; does not affect decision as the code analysis is conclusive)

**YES**

 drivers/gpu/drm/amd/display/dc/dccg/dcn401/dcn401_dccg.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dccg/dcn401/dcn401_dccg.c b/drivers/gpu/drm/amd/display/dc/dccg/dcn401/dcn401_dccg.c
index a37f94dec6f2f..44c4a53f14ad8 100644
--- a/drivers/gpu/drm/amd/display/dc/dccg/dcn401/dcn401_dccg.c
+++ b/drivers/gpu/drm/amd/display/dc/dccg/dcn401/dcn401_dccg.c
@@ -526,10 +526,6 @@ static void dccg401_enable_dpstreamclk(struct dccg *dccg, int otg_inst, int dp_h
 		BREAK_TO_DEBUGGER();
 		return;
 	}
-	if (dccg->ctx->dc->debug.root_clock_optimization.bits.dpstream)
-		REG_UPDATE_2(DCCG_GATE_DISABLE_CNTL3,
-			DPSTREAMCLK_GATE_DISABLE, 1,
-			DPSTREAMCLK_ROOT_GATE_DISABLE, 1);
 }
 
 void dccg401_disable_dpstreamclk(struct dccg *dccg, int dp_hpo_inst)
-- 
2.53.0

[PATCH AUTOSEL 7.0] drm/amdgpu: Add default reset method for soc_v1_0

[Sasha Levin]

From: Asad Kamal <asad.kamal@amd.com>

[ Upstream commit eb737fb303dd73ceb0f646fc2e696595e576056f ]

Add mode2 as default reset method for soc_v1_0

v2: Remove unnecessary overrides while selecting reset method (Lijo)
v4: Add dev_warn_once (Lijo)

Signed-off-by: Asad Kamal <asad.kamal@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the evidence I need. Let me compile my analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `drm/amdgpu`
- Action verb: "Add" (default reset method)
- Summary: Adds mode2 as the default reset method for soc_v1_0.
- Record: [drm/amdgpu] [Add] [Default reset method for soc_v1_0 -
  filling in a missing required callback]

**Step 1.2: Tags**
- Signed-off-by: Asad Kamal (author, AMD developer)
- Reviewed-by: Lijo Lazar (AMD engineer, specifically requested changes
  in v2 and v4)
- Signed-off-by: Alex Deucher (AMD GPU subsystem maintainer)
- No Fixes: tag (expected), no Cc: stable, no Reported-by, no Link.
- Record: Reviewed by AMD engineer, signed off by subsystem maintainer.
  No syzbot or bug reports.

**Step 1.3: Commit Body**
- The commit message is minimal: "Add mode2 as default reset method for
  soc_v1_0"
- v2: Removed unnecessary overrides (Lijo's suggestion)
- v4: Added dev_warn_once (Lijo's suggestion)
- No bug description, no stack trace, no reproduction steps.
- Record: The message describes feature completion but the underlying
  issue is that `soc_v1_0_asic_funcs` has a NULL `.reset_method`
  pointer.

**Step 1.4: Hidden Bug Fix Detection**
- This IS a hidden bug fix. The `amdgpu_asic_reset_method()` macro at
  `amdgpu.h:1454` dereferences `.reset_method` directly with NO null
  check. Without this patch, any call to
  `amdgpu_asic_reset_method(adev)` on soc_v1_0 hardware dereferences a
  NULL function pointer, causing a kernel oops.
- Record: YES, this is a hidden bug fix - fixes NULL pointer dereference
  of missing `.reset_method` callback.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Single file: `drivers/gpu/drm/amd/amdgpu/soc_v1_0.c`
- +24 lines added, 0 removed
- Functions modified: `soc_v1_0_asic_reset` (filled in stub),
  `soc_v1_0_asic_funcs` (added callback)
- Functions added: `soc_v1_0_asic_reset_method` (new function)
- Record: Single-file, +24 lines, surgical fix

**Step 2.2: Code Flow Change**
- BEFORE: `soc_v1_0_asic_reset` was a stub returning 0 (no-op).
  `.reset_method` was NULL in `soc_v1_0_asic_funcs`.
- AFTER: `soc_v1_0_asic_reset_method` selects Mode2 reset for specific
  hardware configs, or returns the module param default.
  `soc_v1_0_asic_reset` dispatches based on the selected method.
  `.reset_method` callback is populated.

**Step 2.3: Bug Mechanism**
- Category: NULL pointer dereference + missing functionality
- The `amdgpu_asic_reset_method` macro (amdgpu.h:1454) calls
  `(adev)->asic_funcs->reset_method((adev))` without NULL check.
  Multiple callers in `amdgpu_device.c` and `amdgpu_reset.c` invoke this
  during GPU reset paths. Without `.reset_method` set, this is a NULL
  deref crash.
- Record: NULL pointer dereference in GPU reset path. All other SoC
  variants (si, cik, vi, soc15, soc21, soc24, nv) set `.reset_method` —
  soc_v1_0 was the only one missing it.

**Step 2.4: Fix Quality**
- Obviously correct — follows exact same pattern as soc24, soc21, soc15,
  etc.
- Minimal and surgical
- Low regression risk — only affects soc_v1_0 hardware
- Minor dead code: `return 0;` after the switch in `soc_v1_0_asic_reset`
  is unreachable (both cases return), but harmless.
- Record: High quality fix, follows established patterns, low regression
  risk.

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
- The buggy code (stub `soc_v1_0_asic_reset` and missing
  `.reset_method`) was introduced in commit `297b0cebbcc3a`
  ("drm/amdgpu: Add soc v1_0 support") by Hawking Zhang on 2025-12-08.
  The original commit even noted "reset placeholders" in its changelog
  (v3).
- Record: Bug introduced in 297b0cebbcc3a, v7.0-rc1. Explicitly noted as
  "placeholder" in original commit.

**Step 3.2: No Fixes: tag to follow.**

**Step 3.3: File History**
- 11 commits touch soc_v1_0.c, all building out the new soc_v1_0 driver.
  No intermediate fix for the reset method issue.
- Record: Standalone fix. No prerequisites needed beyond the initial
  soc_v1_0 support.

**Step 3.4: Author**
- Asad Kamal is an AMD developer with multiple commits in the PM and GPU
  subsystem.
- Alex Deucher (AMD GPU maintainer) signed off and submitted the patch
  series.
- Record: Author is AMD developer, maintainer signed off.

**Step 3.5: Dependencies**
- The companion patch "Disable reset on init for soc_v1_0" starts from
  this commit's output hash (bd7043729e6a3), so it depends on this
  patch. This patch does NOT depend on any other uncommitted patches.
- Record: This patch is standalone and applies independently. A
  companion patch depends on it.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Patch Discussion**
- Found on spinics: `https://www.spinics.net/lists/amd-
  gfx/msg138861.html`
- Part of a series of soc_v1_0 fixes posted by Alex Deucher on
  2026-03-06
- The series includes ~12 related patches for soc_v1_0 and related
  hardware
- Patch went through v1 → v2 (removed unnecessary overrides) → v4 (added
  dev_warn_once)
- No explicit stable nomination in the discussion
- Record: Found submission thread. Multi-revision patch, review-driven
  improvements. No NAKs.

**Step 4.2: Reviewers**
- Reviewed-by: Lijo Lazar (AMD engineer who provided specific feedback
  driving v2 and v4 changes)
- Signed-off-by: Alex Deucher (subsystem maintainer)
- Record: Properly reviewed by AMD engineers.

**Step 4.3: Bug Report**
- No formal bug report or syzbot report. This is a proactive fix for
  missing functionality that would crash on GPU reset.
- Record: No bug report; proactive fix for obviously broken code.

**Step 4.4: Related Patches**
- Companion patch "Disable reset on init for soc_v1_0" removes the
  always-true `need_reset_on_init` logic. This is NOT in the 7.0 tree
  yet.
- Record: Companion patch exists but this commit is standalone.

**Step 4.5: Stable Discussion**
- No stable-specific discussion found.
- Record: No stable discussion.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions**
- New: `soc_v1_0_asic_reset_method`
- Modified: `soc_v1_0_asic_reset`, `soc_v1_0_asic_funcs`

**Step 5.2: Callers**
- `amdgpu_asic_reset_method(adev)` is called from:
  - `amdgpu_device.c:3216` — `amdgpu_device_check_vram_lost()` (during
    reset)
  - `amdgpu_device.c:4179` — `amdgpu_device_xgmi_reset_work()` (XGMI
    reset)
  - `amdgpu_device.c:6114` — `amdgpu_device_set_mp1_state()` (during
    reset)
  - `amdgpu_device.c:6158` — `amdgpu_device_suspend_display_audio()`
    (during reset)
  - `amdgpu_reset.c:113` — XGMI reset path
  - `amdgpu_ras.c:4885` — RAS error handling
- These are all common GPU reset/recovery code paths.
- Record: The NULL `.reset_method` is dereferenced from multiple common
  code paths during GPU hang recovery.

**Step 5.3-5.5: Call Chain / Similar Patterns**
- Every other SoC variant (si, cik, vi, nv, soc15, soc21, soc24) has
  `.reset_method` populated. soc_v1_0 was the only one missing it.
- Record: Systematic omission — soc_v1_0 was incomplete compared to all
  sibling drivers.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code Existence**
- soc_v1_0.c was introduced in v7.0-rc1 (commit 297b0cebbcc3a). It
  exists in v7.0.
- Only relevant for 7.0.y stable tree.
- Record: Bug exists in 7.0.y only.

**Step 6.2: Backport Complications**
- The diff applies against the base hash `26e7566a5479c`, which is the
  current state in v7.0. Should apply cleanly.
- Record: Clean apply expected for 7.0.y.

**Step 6.3: Related Fixes in Stable**
- No related fixes found in stable.
- Record: None.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem**
- `drivers/gpu/drm/amd/amdgpu` — AMD GPU driver
- Criticality: IMPORTANT — affects users of AMD GPUs with GC 12.1
  hardware
- Record: GPU driver, IMPORTANT criticality.

**Step 7.2: Activity**
- Very active subsystem — 40 changes between v7.0-rc1 and v7.0 in amdgpu
  alone.
- Record: Highly active, new hardware being brought up.

## PHASE 8: IMPACT AND RISK

**Step 8.1: Affected Users**
- Users with soc_v1_0 (GC 12.1) AMD GPU hardware running kernel 7.0.y
- Record: Driver-specific, but for current-gen AMD hardware.

**Step 8.2: Trigger Conditions**
- Any GPU hang or error that triggers the GPU reset recovery path will
  hit the NULL deref.
- GPU hangs can happen during normal operation (driver bugs, power
  management issues, etc.)
- Record: Triggered by GPU reset, which can happen during normal GPU
  usage.

**Step 8.3: Failure Mode**
- NULL pointer dereference → kernel oops/panic
- Severity: CRITICAL
- Record: Kernel crash during GPU reset recovery.

**Step 8.4: Risk-Benefit**
- BENEFIT: HIGH — prevents kernel crash on GPU reset for soc_v1_0
  hardware
- RISK: LOW — 24 lines in a single file, follows exact pattern of all
  sibling SoC variants, only affects soc_v1_0 hardware
- Record: High benefit, low risk.

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Summary**

FOR backporting:
- Fixes NULL pointer dereference (kernel crash) — CRITICAL severity
- Small, contained (24 lines, single file)
- Follows exact pattern of all other SoC variants (si, cik, vi, nv,
  soc15, soc21, soc24)
- Reviewed by AMD engineer, signed off by AMD GPU subsystem maintainer
- The bug is in code shipped in v7.0; users with this hardware will hit
  it on any GPU hang
- Standalone patch, no dependencies

AGAINST backporting:
- No explicit Cc: stable or Fixes: tag (expected — that's why it's being
  reviewed)
- Could be seen as "feature completion" rather than "bug fix"
- Very new code (soc_v1_0 only in v7.0)
- No reported user impact yet (hardware may be very new)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? YES — follows identical pattern in 7
   other SoC variants, reviewed by AMD
2. Fixes a real bug? YES — NULL pointer dereference on GPU reset
3. Important issue? YES — kernel crash (CRITICAL)
4. Small and contained? YES — 24 lines, single file
5. No new features? BORDERLINE — adds required callback, but the
   functionality is not "new" (all other variants have it)
6. Can apply to stable? YES — applies cleanly to 7.0.y

**Step 9.3: Exception Categories**
- Not a standard exception category, but fixes a crash in new hardware
  support that shipped in v7.0.

**Step 9.4: Decision**
The missing `.reset_method` callback in `soc_v1_0_asic_funcs` causes a
NULL pointer dereference whenever GPU reset is triggered on this
hardware. This is a CRITICAL crash bug. The fix is 24 lines, self-
contained, follows established patterns from all other AMD GPU SoC
variants, and was reviewed by AMD engineers including the subsystem
maintainer. While it could be characterized as "completing" the driver,
the practical effect is fixing a kernel crash.

## Verification

- [Phase 1] Parsed tags: Reviewed-by: Lijo Lazar, Signed-off-by: Alex
  Deucher (maintainer). No syzbot/Fixes/Cc:stable.
- [Phase 2] Diff analysis: +24 lines in soc_v1_0.c. Adds
  `soc_v1_0_asic_reset_method` function, fills in `soc_v1_0_asic_reset`
  stub, populates `.reset_method` in asic_funcs.
- [Phase 2] Verified: `amdgpu_asic_reset_method` macro at amdgpu.h:1454
  dereferences `.reset_method` with NO null check.
- [Phase 2] Verified: All other SoC variants (si, cik, vi, nv, soc15,
  soc21, soc24) have `.reset_method` set. soc_v1_0 is the only one
  missing it.
- [Phase 3] git blame: buggy stub introduced in commit 297b0cebbcc3a
  (2025-12-08), present since v7.0-rc1. Original commit described it as
  "reset placeholders."
- [Phase 3] git tag: 297b0cebbcc3a is contained in v7.0-rc1, v7.0.
- [Phase 3] git log: 11 commits touch soc_v1_0.c, none fix the reset
  method issue.
- [Phase 4] Found original submission: spinics.net/lists/amd-
  gfx/msg138861.html — part of series by Alex Deucher on 2026-03-06
- [Phase 4] Patch evolved v1→v2→v4, review-driven improvements, no NAKs
- [Phase 4] Companion patch "Disable reset on init for soc_v1_0" exists
  and depends on this commit
- [Phase 5] Verified callers: `amdgpu_asic_reset_method()` called from
  amdgpu_device.c:3216, 4179, 6114, 6158 and amdgpu_reset.c:113 — all
  GPU reset code paths
- [Phase 6] Code exists only in v7.0 (soc_v1_0 introduced in v7.0-rc1)
- [Phase 8] Failure mode: NULL deref → kernel oops on GPU reset,
  severity CRITICAL
- UNVERIFIED: Whether any users have actually triggered this crash
  (hardware is very new)

**YES**

 drivers/gpu/drm/amd/amdgpu/soc_v1_0.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/soc_v1_0.c b/drivers/gpu/drm/amd/amdgpu/soc_v1_0.c
index 59ab952d5cce4..ca66a0169c781 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc_v1_0.c
@@ -229,8 +229,31 @@ static bool soc_v1_0_need_reset_on_init(struct amdgpu_device *adev)
 	return false;
 }
 
+static enum amd_reset_method
+soc_v1_0_asic_reset_method(struct amdgpu_device *adev)
+{
+	if ((adev->gmc.xgmi.supported && adev->gmc.xgmi.connected_to_cpu) ||
+	    (amdgpu_ip_version(adev, MP1_HWIP, 0) == IP_VERSION(15, 0, 8))) {
+		if (amdgpu_reset_method != -1)
+			dev_warn_once(adev->dev, "Reset override isn't supported, using Mode2 instead.\n");
+
+		return AMD_RESET_METHOD_MODE2;
+	}
+
+	return amdgpu_reset_method;
+}
+
 static int soc_v1_0_asic_reset(struct amdgpu_device *adev)
 {
+	switch (soc_v1_0_asic_reset_method(adev)) {
+	case AMD_RESET_METHOD_MODE2:
+		dev_info(adev->dev, "MODE2 reset\n");
+		return amdgpu_dpm_mode2_reset(adev);
+	default:
+		dev_info(adev->dev, "Invalid reset method Not supported\n");
+		return -EOPNOTSUPP;
+	}
+
 	return 0;
 }
 
@@ -244,6 +267,7 @@ static const struct amdgpu_asic_funcs soc_v1_0_asic_funcs = {
 	.need_reset_on_init = &soc_v1_0_need_reset_on_init,
 	.encode_ext_smn_addressing = &soc_v1_0_encode_ext_smn_addressing,
 	.reset = soc_v1_0_asic_reset,
+	.reset_method = &soc_v1_0_asic_reset_method,
 };
 
 static int soc_v1_0_common_early_init(struct amdgpu_ip_block *ip_block)
-- 
2.53.0

[PATCH AUTOSEL 7.0] drm/amdgpu/userq: cleanup amdgpu_userq_get/put where not needed

[Sasha Levin]

From: Sunil Khatri <sunil.khatri@amd.com>

[ Upstream commit 8f402ddd4f2321485fff7384c003124681a08146 ]

amdgpu_userq_put/get are not needed in case we already holding
the userq_mutex and reference is valid already from queue create
time or from signal ioctl. These additional get/put could be a
potential reason for deadlock in case the ref count reaches zero
and destroy is called which again try to take the userq_mutex.

Due to the above change we avoid deadlock between suspend/restore
calling destroy queues trying to take userq_mutex again.

Cc: Prike Liang <Prike.Liang@amd.com>
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a thorough analysis. Let me
compile the findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `drm/amdgpu/userq`
- Action verb: "cleanup" (but this is a hidden deadlock fix)
- Summary: Remove unnecessary `amdgpu_userq_get/put` calls that cause
  deadlock

**Step 1.2: Tags**
- `Cc: Prike Liang <Prike.Liang@amd.com>` - CC'd related developer
- `Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>` - author
- `Reviewed-by: Christian König <christian.koenig@amd.com>` - key
  DRM/AMDGPU maintainer reviewed
- `Signed-off-by: Alex Deucher <alexander.deucher@amd.com>` - AMDGPU
  maintainer committed

**Step 1.3: Commit Body Analysis**
The commit explains:
- The `get/put` calls are unnecessary when `userq_mutex` is already held
  and references are valid from creation or signal ioctl
- The extra `put` could trigger `amdgpu_userq_kref_destroy` ->
  `amdgpu_userq_destroy` which tries to acquire `userq_mutex` again ->
  **deadlock**
- Specifically calls out suspend/restore as a deadlock-triggering path

**Step 1.4: Hidden Bug Fix Detection**
YES - this is a deadlock fix disguised as "cleanup". The commit message
explicitly describes a deadlock scenario.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Single file: `drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c`
- Approximately 20 lines removed, 0 lines added (pure removal)
- Functions modified: `amdgpu_userq_restore_all`,
  `amdgpu_userq_evict_all`, `amdgpu_userq_wait_for_signal`

**Step 2.2: Code Flow Change**
Three functions all have the same pattern changed:

BEFORE: Inside `xa_for_each` loop: `amdgpu_userq_get()` -> work ->
`amdgpu_userq_put()`
AFTER: Inside `xa_for_each` loop: work (no get/put)

**Step 2.3: Bug Mechanism**
Category: **Deadlock** (lock ordering / recursive mutex acquisition)

The full deadlock chain I verified:
1. `amdgpu_userq_restore_worker` (line 1279) or
   `amdgpu_eviction_fence_suspend_worker`
   (`amdgpu_eviction_fence.c:110`) acquires `userq_mutex`
2. Calls one of the three modified functions
3. Function does `amdgpu_userq_put()` (line 698-702) ->
   `kref_put(&queue->refcount, amdgpu_userq_kref_destroy)`
4. If refcount hits zero -> `amdgpu_userq_kref_destroy` (line 673-682)
   -> `amdgpu_userq_destroy` (line 626-671)
5. `amdgpu_userq_destroy` calls `mutex_lock(&uq_mgr->userq_mutex)` at
   line 633 -> **DEADLOCK**

**Step 2.4: Fix Quality**
- Obviously correct: the mutex is already held, preventing concurrent
  destroy; `xa_for_each` provides a valid entry pointer under RCU
- Minimal/surgical: purely removes code, no new logic
- Regression risk: very low. The only concern would be if a queue could
  be destroyed between loop iterations without the extra get holding a
  reference, but the `userq_mutex` prevents that

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
The `amdgpu_userq_get/put` calls in these three functions were all
introduced by commit `65b5c326ce410` ("drm/amdgpu/userq: refcount
userqueues to avoid any race conditions") dated 2026-03-02, the same
author (Sunil Khatri). This refcount commit is present in v7.0.

**Step 3.2: Fixes Tag / Predecessor**
The refcount commit `65b5c326ce410` is cherry-picked from mainline
`4952189b284d4d847f92636bb42dd747747129c0` and is explicitly tagged `Cc:
<stable@vger.kernel.org>`. It is already in the 7.0 stable tree and is
intended for other stable trees too.

**Step 3.3: File History**
The commit `a018d1819f158` (doorbell_offset validation) is the only
commit after the refcount commit in this tree. No conflicting changes.

**Step 3.4: Author**
Sunil Khatri is a regular AMD GPU contributor who also authored the
refcount commit that introduced the bug. This is the same author fixing
their own mistake, which is common and provides high confidence in the
fix.

**Step 3.5: Dependencies**
This commit depends ONLY on `65b5c326ce410` (the refcount commit) being
present. Since that commit is already in the 7.0 tree and tagged for
stable, the dependency is satisfied.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1-4.2:**
Found via b4 dig that the refcount commit was submitted as "[PATCH v4]"
at `https://patch.msgid.link/20260303120654.2582995-1-
sunil.khatri@amd.com`. The patch went through v1-v4 with review by
Christian König and Alex Deucher. Lore.kernel.org was behind anti-bot
protection, so full discussion thread was not accessible.

**Step 4.3-4.5:**
The fix is by the same author who introduced the problem in the refcount
commit. Christian König (key DRM maintainer) reviewed both the original
refcount commit and this cleanup fix, confirming its correctness.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Key Functions**
- `amdgpu_userq_restore_all` - restores all queues after eviction
- `amdgpu_userq_evict_all` - evicts all queues
- `amdgpu_userq_wait_for_signal` - waits for last fences

**Step 5.2: Callers**
- `amdgpu_userq_restore_all`: called from `amdgpu_userq_restore_worker`
  (workqueue, holds `userq_mutex` at line 1279)
- `amdgpu_userq_evict_all`: called from `amdgpu_userq_evict`, which is
  called from `amdgpu_eviction_fence_suspend_worker` (holds
  `userq_mutex` at `amdgpu_eviction_fence.c:110`)
- `amdgpu_userq_wait_for_signal`: called from `amdgpu_userq_evict`, same
  path as above

**Step 5.4: Reachability**
These are GPU suspend/resume/eviction paths - triggered during system
suspend, GPU recovery, and memory pressure. These are common operations
for any AMD GPU user.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable**
The buggy code (`amdgpu_userq_get/put` in these three functions) was
introduced by `65b5c326ce410` which is:
- Present in v7.0 stable (confirmed)
- Tagged `Cc: stable@vger.kernel.org` - intended for all stable trees
  that have the userq infrastructure

**Step 6.2: Backport Complications**
The patch is a pure line removal from the same file modified by the
refcount commit. It should apply cleanly to any tree that has the
refcount commit.

**Step 6.3: Related Fixes Already in Stable**
No other fix for this deadlock was found in the tree.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:** GPU driver (drivers/gpu/drm/amd/amdgpu) - IMPORTANT
criticality. AMD GPU is one of the most widely used GPU subsystems in
Linux.

**Step 7.2:** Actively developed - the userq (user queue) infrastructure
is a recent feature with many ongoing changes.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
All users with AMD GPUs using usermode queues.

**Step 8.2: Trigger Conditions**
- System suspend/resume triggers the restore path
- Memory pressure triggers eviction path
- GPU recovery triggers eviction path
These are common operations - not exotic scenarios.

**Step 8.3: Failure Mode**
**CRITICAL** - Deadlock. The system hangs with the `userq_mutex` held,
which blocks all subsequent GPU queue operations. This is a hard hang
for the GPU subsystem.

**Step 8.4: Risk-Benefit**
- **Benefit**: HIGH - prevents deadlock during suspend/resume/eviction
  on AMD GPUs
- **Risk**: VERY LOW - purely removes code, no new logic, reviewed by
  Christian König
- The removal is correct because: (a) `userq_mutex` is held preventing
  concurrent destruction, (b) `xa_for_each` provides valid entry
  pointers, (c) the extra get/put is redundant

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Summary**

FOR backporting:
- Fixes a real deadlock (recursive mutex acquisition) in GPU
  suspend/resume/eviction
- The refcount commit that introduced the bug is already tagged for
  stable
- Single file, ~20 lines removed, no new code
- Reviewed by Christian König (key DRM maintainer)
- Fix by the same author who introduced the bug
- Trigger conditions are common (suspend/resume, GPU recovery)
- Obviously correct - removing redundant reference counting under held
  mutex

AGAINST backporting:
- No explicit `Cc: stable@vger.kernel.org` on this commit (expected -
  that's why it's being reviewed)
- No `Fixes:` tag (expected)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** - simple removal, reviewed by
   maintainer
2. Fixes a real bug? **YES** - deadlock during suspend/resume/eviction
3. Important issue? **YES** - deadlock (system hang)
4. Small and contained? **YES** - ~20 lines removed, single file
5. No new features or APIs? **YES** - pure removal
6. Can apply to stable? **YES** - applies to any tree with the refcount
   commit

**Step 9.3: Exception Categories**
Not needed - this qualifies as a standard important bug fix (deadlock).

## Verification

- [Phase 1] Parsed tags: Reviewed-by Christian König, Signed-off-by Alex
  Deucher (both AMDGPU maintainers)
- [Phase 2] Diff analysis: ~20 lines removed from 3 functions, removing
  redundant `amdgpu_userq_get/put` pairs
- [Phase 2] Deadlock chain verified: `restore_worker`(mutex) ->
  `restore_all` -> `put` -> `kref_destroy` -> `destroy` -> `mutex_lock`
  = DEADLOCK
- [Phase 3] git blame: buggy get/put added by `65b5c326ce410` (Sunil
  Khatri, 2026-03-02), present in v7.0
- [Phase 3] Confirmed `65b5c326ce410` is cherry-picked from mainline
  `4952189b284d4d847f92636bb42dd747747129c0` with `Cc:
  stable@vger.kernel.org`
- [Phase 3] Same author (Sunil Khatri) for both the bug-introducing and
  fixing commits
- [Phase 4] b4 dig found original refcount submission at `https://patch.
  msgid.link/20260303120654.2582995-1-sunil.khatri@amd.com`, went
  through v1-v4
- [Phase 5] Verified callers: `amdgpu_userq_restore_worker` holds mutex
  at line 1279; `amdgpu_eviction_fence_suspend_worker` holds mutex at
  `amdgpu_eviction_fence.c:110`
- [Phase 5] Verified `amdgpu_userq_destroy` takes mutex at line 633
  (confirmed the deadlock)
- [Phase 5] Verified `amdgpu_userq_kref_destroy` (line 673) calls
  `amdgpu_userq_destroy` (line 680)
- [Phase 6] Refcount commit exists in 7.0 stable and is tagged for all
  stable trees
- [Phase 8] Failure mode: DEADLOCK in GPU suspend/resume - severity
  CRITICAL

This is a clear, well-reviewed deadlock fix for a bug introduced by a
commit already in stable. The fix is minimal (pure removal), correct,
and addresses a critical stability issue during suspend/resume.

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 21 +++------------------
 1 file changed, 3 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
index ad39460b54dc5..2c98bce88b9dd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
@@ -1057,15 +1057,11 @@ amdgpu_userq_restore_all(struct amdgpu_userq_mgr *uq_mgr)
 
 	/* Resume all the queues for this process */
 	xa_for_each(&uq_mgr->userq_xa, queue_id, queue) {
-		queue = amdgpu_userq_get(uq_mgr, queue_id);
-		if (!queue)
-			continue;
 
 		if (!amdgpu_userq_buffer_vas_mapped(queue)) {
 			drm_file_err(uq_mgr->file,
 				     "trying restore queue without va mapping\n");
 			queue->state = AMDGPU_USERQ_STATE_INVALID_VA;
-			amdgpu_userq_put(queue);
 			continue;
 		}
 
@@ -1073,7 +1069,6 @@ amdgpu_userq_restore_all(struct amdgpu_userq_mgr *uq_mgr)
 		if (r)
 			ret = r;
 
-		amdgpu_userq_put(queue);
 	}
 
 	if (ret)
@@ -1307,13 +1302,9 @@ amdgpu_userq_evict_all(struct amdgpu_userq_mgr *uq_mgr)
 	amdgpu_userq_detect_and_reset_queues(uq_mgr);
 	/* Try to unmap all the queues in this process ctx */
 	xa_for_each(&uq_mgr->userq_xa, queue_id, queue) {
-		queue = amdgpu_userq_get(uq_mgr, queue_id);
-		if (!queue)
-			continue;
 		r = amdgpu_userq_preempt_helper(queue);
 		if (r)
 			ret = r;
-		amdgpu_userq_put(queue);
 	}
 
 	if (ret)
@@ -1346,24 +1337,18 @@ amdgpu_userq_wait_for_signal(struct amdgpu_userq_mgr *uq_mgr)
 	int ret;
 
 	xa_for_each(&uq_mgr->userq_xa, queue_id, queue) {
-		queue = amdgpu_userq_get(uq_mgr, queue_id);
-		if (!queue)
-			continue;
-
 		struct dma_fence *f = queue->last_fence;
 
-		if (!f || dma_fence_is_signaled(f)) {
-			amdgpu_userq_put(queue);
+		if (!f || dma_fence_is_signaled(f))
 			continue;
-		}
+
 		ret = dma_fence_wait_timeout(f, true, msecs_to_jiffies(100));
 		if (ret <= 0) {
 			drm_file_err(uq_mgr->file, "Timed out waiting for fence=%llu:%llu\n",
 				     f->context, f->seqno);
-			amdgpu_userq_put(queue);
+
 			return -ETIMEDOUT;
 		}
-		amdgpu_userq_put(queue);
 	}
 
 	return 0;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] drm/amdgpu: fix some more bug in amdgpu_gem_va_ioctl

[Sasha Levin]

From: Christian König <christian.koenig@amd.com>

[ Upstream commit 68bd4f6b8310f309eb63b41e15088690c9cec0a9 ]

Some illegal combination of input flags were not checked and we need to
take the PDEs into account when returning the fence as well.

Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Sunil Khatri <sunil.khatri@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed. Here is my complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: drm/amdgpu
- **Action verb**: "fix" (explicit bug fix)
- **Summary**: Fix multiple bugs in the `amdgpu_gem_va_ioctl` function
  related to input flag validation and fence handling for PDE updates.

Record: [drm/amdgpu] [fix] [Multiple bugs in gem VA ioctl: illegal flag
combinations and missing PDE fence]

### Step 1.2: Tags
- **Signed-off-by**: Christian König (author, AMD DRM subsystem co-
  maintainer)
- **Acked-by**: Sunil Khatri (AMD developer)
- **Signed-off-by**: Alex Deucher (AMD DRM maintainer, committer)
- No Fixes: tag, no Reported-by, no Link: tag

Record: Author is Christian König, one of the primary amdgpu/drm
maintainers. Acked by AMD colleague, committed by the AMD DRM
maintainer.

### Step 1.3: Commit Body
The body says: "Some illegal combination of input flags were not checked
and we need to take the PDEs into account when returning the fence as
well."

Two distinct bugs identified:
1. Missing input validation for contradictory flag combinations
2. Missing PDE (Page Directory Entry) fence in the returned fence to
   userspace

Record: [Bug 1: invalid flag combinations not rejected] [Bug 2: PDE
updates missing from returned fence, could cause premature GPU memory
access] [No version info given] [Root cause: incomplete validation and
incomplete fence merging]

### Step 1.4: Hidden Bug Fix Detection
This is an explicit "fix" commit, not disguised as cleanup.

Record: This is explicitly labeled as a bug fix. No hidden intent.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **File**: `drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c` (1 file)
- **Added**: `#include <linux/dma-fence-unwrap.h>` (1 line)
- **Functions modified**: `amdgpu_gem_va_update_vm()`,
  `amdgpu_gem_va_ioctl()`
- **Scope**: ~35 lines removed, ~30 lines added in
  `amdgpu_gem_va_update_vm`; ~10 lines changed in `amdgpu_gem_va_ioctl`

Record: [1 file, ~45 lines changed, 2 functions modified] [Single-file
contained fix]

### Step 2.2: Code Flow Changes

**Hunk 1 - `amdgpu_gem_va_update_vm` - VM-not-ready path**:
- Before: `fence = dma_fence_get(vm->last_update)` then if not ready,
  return that fence
- After: If not ready, return `dma_fence_get_stub()` immediately
- Effect: Cleaner early return; stub fence is sufficient when VM isn't
  ready

**Hunk 2 - `amdgpu_vm_clear_freed` argument**:
- Before: `amdgpu_vm_clear_freed(adev, vm, &fence)` (local variable)
- After: `amdgpu_vm_clear_freed(adev, vm, &vm->last_update)` (VM state
  directly)
- Effect: `vm->last_update` is kept current after clearing freed
  mappings, so subsequent `amdgpu_vm_update_pdes` properly syncs

**Hunk 3 - Fence return logic**:
- Before: Switch/case returning either `vm->last_update` or
  `bo_va->last_pt_update` (but NOT both)
- After: For non-always-valid MAP/REPLACE, merges both `vm->last_update`
  and `bo_va->last_pt_update` using `dma_fence_unwrap_merge()`; includes
  OOM fallback; for other cases returns `vm->last_update`
- Effect: Returned fence now accounts for both PTE and PDE updates

**Hunk 4 - Error path**:
- Before: Falls through from normal path to error label, always returns
  local fence
- After: Normal path returns fence via explicit `return`; error path
  returns `dma_fence_get(vm->last_update)`
- Effect: Cleaner separation of normal and error paths

**Hunk 5 - `amdgpu_gem_va_ioctl` - flag validation**:
- Added check: `AMDGPU_VM_DELAY_UPDATE && vm_timeline_syncobj_out`
  returns -EINVAL
- Effect: Rejects contradictory flags (delay + immediate fence request)

**Hunk 6 - `amdgpu_gem_va_ioctl` - update condition**:
- Before: `!adev->debug_vm`
- After: `(!adev->debug_vm || timeline_syncobj)`
- Effect: When timeline syncobj is requested, update happens even in
  debug mode

Record: [6 distinct hunks, all fixing correctness issues]

### Step 2.3: Bug Mechanism
This is a **logic/correctness fix** with two aspects:
1. **Missing fence merge**: `amdgpu_vm_update_pdes()` stores its fence
   into `vm->last_update` (verified at `amdgpu_vm.c:1006`). For non-
   always-valid BOs on MAP/REPLACE, the old code returned only
   `bo_va->last_pt_update`, missing the PDE fence. Userspace could start
   using the mapping before PDE updates complete.
2. **Input validation gap**: DELAY_UPDATE + syncobj_out is contradictory
   and wasn't rejected.

Record: [Logic/correctness fix] [Missing PDE fence could cause premature
GPU memory access; missing input validation for contradictory flags]

### Step 2.4: Fix Quality
- The fix uses `dma_fence_unwrap_merge()` which is the correct API for
  merging fences
- OOM fallback with `dma_fence_wait` + `dma_fence_get_stub()` is
  reasonable
- The flag validation check is trivially correct
- The debug_vm condition change is obviously correct
- Low regression risk: the fence merge is strictly more conservative
  (waits for more work)

Record: [Fix is well-designed with proper fallback] [Low regression risk
- waits for MORE work, not less]

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
The code being modified was primarily introduced by:
- `efdc66fe12b07` (2026-01-09) - "Refactor amdgpu_gem_va_ioctl v7"
- `bd8150a1b3370` (2025-12-11) - "Refactor amdgpu_gem_va_ioctl v4"

Both are in v7.0-rc1/v7.0. The bugs were introduced in the v7.0 cycle.

Record: [Buggy code from efdc66fe12b07 and bd8150a1b3370, both v7.0
cycle]

### Step 3.2: Fixes tag
No Fixes: tag present. The bugs were introduced by `bd8150a1b3370` and
partially addressed by `efdc66fe12b07`, but this commit fixes remaining
issues in `efdc66fe12b07`.

Record: [No explicit Fixes: tag; fixes bugs remaining from
efdc66fe12b07]

### Step 3.3: File History
44 commits changed this file since v6.12. The specific area
(va_update_vm, va_ioctl) has been actively modified in the v7.0 cycle
with bd8150a1b3370 and efdc66fe12b07.

Record: [Active development area; this is a follow-up fix for recent
refactoring]

### Step 3.4: Author
Christian König is one of the primary amdgpu/drm TTM maintainers. He
authored many critical fixes in this subsystem. He also
suggested/reviewed the v7 refactor that this commit fixes further. His
fixes carry high weight.

Record: [Author is subsystem co-maintainer with deep expertise]

### Step 3.5: Dependencies
- Depends on `efdc66fe12b07` (present in tree as v7.0)
- Requires `dma_fence_unwrap_merge` (present in tree via
  `include/linux/dma-fence-unwrap.h`)
- Requires `amdgpu_vm_is_bo_always_valid` (present in tree)
- The patch context matches the current tree state exactly - clean apply
  expected

Record: [All dependencies present in 7.0 tree; should apply cleanly]

---

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1: Original Discussion
lore.kernel.org blocked automated access. However, I found via b4 dig
that the predecessor commit (`efdc66fe12b07`) was submitted as v7 of the
refactoring series, meaning the fence handling went through 7 iterations
of review. The current fix is by Christian König himself who guided the
entire refactoring.

Record: [Unable to access lore directly; predecessor went through 7
review iterations]

### Step 4.2: Reviewers
- Christian König (author) - AMD DRM co-maintainer
- Sunil Khatri (acker) - AMD developer
- Alex Deucher (committer) - AMD DRM maintainer

Record: [Reviewed by top AMD DRM maintainers]

### Step 4.3-4.5: Bug Reports / Related Patches / Stable Discussion
The predecessor commits (`bd8150a1b3370`) had a documented crash
signature (refcount underflow, use-after-free, kernel panic). While
`efdc66fe12b07` fixed the worst of it, this commit addresses remaining
correctness issues.

Record: [Predecessor had kernel panic crash signature; this fixes
remaining issues]

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
- `amdgpu_gem_va_update_vm()` - updates VM page tables after VA
  operation
- `amdgpu_gem_va_ioctl()` - userspace-facing ioctl handler

### Step 5.2: Callers
`amdgpu_gem_va_ioctl` is the DRM ioctl handler called via
`DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, ...)` at `amdgpu_drv.c:3082`. It's
callable by any process with DRM_AUTH|DRM_RENDER_ALLOW. This is a hot
path for all AMD GPU userspace (Mesa, ROCm, etc.).

`amdgpu_gem_va_update_vm` is called only from `amdgpu_gem_va_ioctl`.

Record: [Directly callable from userspace; affects all AMD GPU users]

### Step 5.4: Reachability
The buggy code path is reachable from any unprivileged process that
opens a DRM render node and performs VM address space management
(standard GPU operation).

Record: [Reachable from unprivileged userspace; common GPU operation
path]

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Code in Stable Trees
`bd8150a1b3370` first appears in v7.0-rc1. It does NOT exist in v6.14 or
earlier stable trees. The timeline syncobj support
(`vm_timeline_syncobj_out`, `AMDGPU_VM_DELAY_UPDATE` in this context) is
v7.0-only functionality. The fix is relevant ONLY for the 7.0.y stable
tree.

Record: [Buggy code only in 7.0.y; not in 6.12.y or earlier]

### Step 6.2: Backport Complications
The diff context matches the current tree state perfectly. Clean apply
expected.

Record: [Clean apply expected for 7.0.y]

### Step 6.3: Related Fixes Already in Stable
`efdc66fe12b07` (the v7 refactor fix) is already in the 7.0 tree, but
this commit fixes remaining issues.

Record: [Predecessor fix present; this addresses additional bugs]

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem
- **Subsystem**: drivers/gpu/drm/amd/amdgpu (GPU driver)
- **Criticality**: IMPORTANT - AMD GPU driver is used by millions of
  users (desktop Linux, server compute, embedded)

Record: [GPU driver, IMPORTANT criticality, affects all AMD GPU users]

### Step 7.2: Subsystem Activity
Very actively developed - 44 changes to this file since v6.12. The VA
ioctl area specifically is being stabilized after recent refactoring.

Record: [Very active; area being stabilized after v7.0 refactoring]

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who Is Affected
All users of AMD GPUs on kernel 7.0.y. This includes desktop,
workstation, and compute users.

Record: [All AMD GPU users on 7.0.y]

### Step 8.2: Trigger Conditions
The missing PDE fence bug triggers during MAP/REPLACE operations on non-
always-valid BOs, which is the normal case for application-managed GPU
memory. This is the common path for all GPU applications. The invalid
flag combination requires specific userspace to pass contradictory
flags.

Record: [PDE fence bug: common GPU operation; flag validation: requires
specific bad input]

### Step 8.3: Failure Mode Severity
- **Missing PDE fence**: Userspace sees mapping as ready before PDE
  updates complete. Could lead to GPU page faults, incorrect GPU memory
  access, or visual corruption. Severity: **HIGH**
- **Invalid flag combination**: Unexpected behavior with contradictory
  flags. Severity: **MEDIUM**
- **debug_vm condition**: Timeline syncobj never signals in debug mode.
  Severity: **MEDIUM** (only affects debug configs)

Record: [HIGH severity for PDE fence bug; MEDIUM for others]

### Step 8.4: Risk-Benefit
- **BENEFIT**: Prevents GPU page faults and incorrect memory access in
  common GPU operations; validates contradictory input flags
- **RISK**: Medium-sized change (~45 lines); restructures fence return
  logic; adds `dma_fence_unwrap_merge` dependency. However, the new
  logic is strictly more conservative (waits for more work) so
  regression risk is low.

Record: [High benefit, low-medium risk; net positive]

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Compilation

**FOR backporting**:
- Fixes real correctness bugs: missing PDE fence, invalid input not
  rejected
- Author is Christian König, AMD DRM co-maintainer with deep expertise
- Acked by AMD developer, committed by AMD DRM maintainer
- Single file change, well-contained
- Userspace-facing ioctl - affects all AMD GPU applications
- The missing PDE fence could cause GPU page faults or incorrect memory
  access
- All dependencies present in 7.0 tree
- Clean apply expected
- The fence merge is strictly more conservative (lower regression risk)

**AGAINST backporting**:
- Medium-sized change (~45 lines), not a tiny surgical fix
- Restructures fence return logic in `amdgpu_gem_va_update_vm`
- Adds new API usage (`dma_fence_unwrap_merge`)
- Bugs only exist in 7.0 code (limited affected trees)
- Area is under active development and may see more changes

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **Yes** - from subsystem maintainer,
   well-reviewed
2. Fixes a real bug? **Yes** - missing PDE fence, invalid input not
   rejected
3. Important issue? **Yes** - GPU page faults, incorrect memory access
   (HIGH severity)
4. Small and contained? **Yes** - single file, ~45 lines, 2 functions
5. No new features or APIs? **Correct** - no new features
6. Can apply to stable? **Yes** - context matches exactly for 7.0.y

### Step 9.3: Exception Categories
Not an exception category; standard bug fix.

### Step 9.4: Decision
The bugs are real and affect all AMD GPU users on 7.0.y. The missing PDE
fence is a correctness issue that can cause GPU page faults during
normal operations. The fix is from the subsystem maintainer, well-
reviewed, contained to a single file, and all dependencies are met.

---

## Verification

- [Phase 1] Parsed tags: Author Christian König (AMD DRM co-maintainer),
  Acked-by Sunil Khatri, committed by Alex Deucher
- [Phase 2] Diff analysis: ~45 lines changed in `amdgpu_gem.c`, modifies
  `amdgpu_gem_va_update_vm` and `amdgpu_gem_va_ioctl`
- [Phase 2] Verified `amdgpu_vm_update_pdes` stores its fence in
  `vm->last_update` (amdgpu_vm.c:1006) - confirms PDE fence is missed
  without the merge
- [Phase 2] Verified `amdgpu_vm_clear_freed` replaces `*fence` when work
  is done (amdgpu_vm.c:1583-1588) - confirms changing argument from
  `&fence` to `&vm->last_update` keeps VM state current
- [Phase 3] git blame: buggy code from `efdc66fe12b07` (2026-01-09) and
  `bd8150a1b3370` (2025-12-11)
- [Phase 3] git tag --contains: both commits first appear in
  v7.0-rc1/v7.0
- [Phase 3] Author's recent commits: 15 commits in amdgpu, including
  multiple critical fixes
- [Phase 4] b4 dig -c efdc66fe12b07: found v7 submission thread
- [Phase 4] b4 dig -a: patch went through v6->v7 iterations
- [Phase 5] `amdgpu_gem_va_ioctl` is registered as DRM ioctl at
  amdgpu_drv.c:3082 (DRM_AUTH|DRM_RENDER_ALLOW)
- [Phase 6] `bd8150a1b3370` NOT in v6.14 (verified via git log
  v6.12..v6.14); only in v7.0+
- [Phase 6] `dma_fence_unwrap_merge` exists in tree (include/linux/dma-
  fence-unwrap.h:69)
- [Phase 6] Current file state matches diff context exactly - clean
  apply expected
- [Phase 8] PDE fence bug: triggers on all MAP/REPLACE of non-always-
  valid BOs (common path)
- UNVERIFIED: Could not verify lore.kernel.org discussion for the
  specific commit under analysis (bot protection blocked access)

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 76 +++++++++++--------------
 1 file changed, 34 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index a6107109a2b86..c4839cf2dce37 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -30,6 +30,7 @@
 #include <linux/pagemap.h>
 #include <linux/pci.h>
 #include <linux/dma-buf.h>
+#include <linux/dma-fence-unwrap.h>
 
 #include <drm/amdgpu_drm.h>
 #include <drm/drm_drv.h>
@@ -744,11 +745,10 @@ amdgpu_gem_va_update_vm(struct amdgpu_device *adev,
 	struct dma_fence *fence;
 	int r = 0;
 
-	/* Always start from the VM's existing last update fence. */
-	fence = dma_fence_get(vm->last_update);
-
+	/* If the VM is not ready return only a stub. */
 	if (!amdgpu_vm_ready(vm))
-		return fence;
+		return dma_fence_get_stub();
+
 
 	/*
 	 * First clean up any freed mappings in the VM.
@@ -757,7 +757,7 @@ amdgpu_gem_va_update_vm(struct amdgpu_device *adev,
 	 * schedules GPU work. If nothing needs clearing, @fence can remain as
 	 * the original vm->last_update.
 	 */
-	r = amdgpu_vm_clear_freed(adev, vm, &fence);
+	r = amdgpu_vm_clear_freed(adev, vm, &vm->last_update);
 	if (r)
 		goto error;
 
@@ -774,47 +774,34 @@ amdgpu_gem_va_update_vm(struct amdgpu_device *adev,
 	if (r)
 		goto error;
 
-	/*
-	 * Decide which fence best represents the last update:
-	 *
-	 * MAP/REPLACE:
-	 *   - For always-valid mappings, use vm->last_update.
-	 *   - Otherwise, export bo_va->last_pt_update.
-	 *
-	 * UNMAP/CLEAR:
-	 *   Keep the fence returned by amdgpu_vm_clear_freed(). If no work was
-	 *   needed, it can remain as vm->last_pt_update.
-	 *
-	 * The VM and BO update fences are always initialized to a valid value.
-	 * vm->last_update and bo_va->last_pt_update always start as valid fences.
-	 * and are never expected to be NULL.
-	 */
-	switch (operation) {
-	case AMDGPU_VA_OP_MAP:
-	case AMDGPU_VA_OP_REPLACE:
+	if ((operation == AMDGPU_VA_OP_MAP ||
+	     operation == AMDGPU_VA_OP_REPLACE) &&
+	    !amdgpu_vm_is_bo_always_valid(vm, bo_va->base.bo)) {
+
 		/*
-		 * For MAP/REPLACE, return the page table update fence for the
-		 * mapping we just modified. bo_va is expected to be valid here.
+		 * For MAP/REPLACE of non per-VM BOs we need to sync to both the
+		 * bo_va->last_pt_update and vm->last_update or otherwise we
+		 * potentially miss the PDE updates.
 		 */
-		dma_fence_put(fence);
-
-		if (amdgpu_vm_is_bo_always_valid(vm, bo_va->base.bo))
-			fence = dma_fence_get(vm->last_update);
-		else
-			fence = dma_fence_get(bo_va->last_pt_update);
-		break;
-	case AMDGPU_VA_OP_UNMAP:
-	case AMDGPU_VA_OP_CLEAR:
-	default:
-		/* keep @fence as returned by amdgpu_vm_clear_freed() */
-		break;
+		fence = dma_fence_unwrap_merge(vm->last_update,
+					       bo_va->last_pt_update);
+		if (!fence) {
+			/* As fallback in OOM situations */
+			dma_fence_wait(vm->last_update, false);
+			dma_fence_wait(bo_va->last_pt_update, false);
+			fence = dma_fence_get_stub();
+		}
+	} else {
+		fence = dma_fence_get(vm->last_update);
 	}
 
+	return fence;
+
 error:
 	if (r && r != -ERESTARTSYS)
 		DRM_ERROR("Couldn't update BO_VA (%d)\n", r);
 
-	return fence;
+	return dma_fence_get(vm->last_update);
 }
 
 int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
@@ -835,7 +822,6 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
 	struct amdgpu_bo_va *bo_va;
 	struct drm_syncobj *timeline_syncobj = NULL;
 	struct dma_fence_chain *timeline_chain = NULL;
-	struct dma_fence *fence;
 	struct drm_exec exec;
 	uint64_t vm_size;
 	int r = 0;
@@ -887,6 +873,10 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
 		return -EINVAL;
 	}
 
+	if (args->flags & AMDGPU_VM_DELAY_UPDATE &&
+	    args->vm_timeline_syncobj_out)
+		return -EINVAL;
+
 	if ((args->operation != AMDGPU_VA_OP_CLEAR) &&
 	    !(args->flags & AMDGPU_VM_PAGE_PRT)) {
 		gobj = drm_gem_object_lookup(filp, args->handle);
@@ -976,11 +966,13 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
 	 * that represents the last relevant update for this mapping. This
 	 * fence can then be exported to the user-visible VM timeline.
 	 */
-	if (!r && !(args->flags & AMDGPU_VM_DELAY_UPDATE) && !adev->debug_vm) {
+	if (!r && !(args->flags & AMDGPU_VM_DELAY_UPDATE) &&
+	    (!adev->debug_vm || timeline_syncobj)) {
+		struct dma_fence *fence;
+
 		fence = amdgpu_gem_va_update_vm(adev, &fpriv->vm, bo_va,
 						args->operation);
-
-		if (timeline_syncobj && fence) {
+		if (timeline_syncobj) {
 			if (!args->vm_timeline_point) {
 				/* Replace the existing fence when no point is given. */
 				drm_syncobj_replace_fence(timeline_syncobj,
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] drm/amdgpu: fix DF NULL pointer issue for soc24

[Sasha Levin]

From: Likun Gao <Likun.Gao@amd.com>

[ Upstream commit 50808826a64b4957b7088c789e539dd0a75a1560 ]

If DF function not initialized, NULL pointer issue
will happen on soc24.

Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information I need. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
- **Subsystem:** `drm/amdgpu` (AMD GPU driver)
- **Action verb:** "fix" - explicitly a bug fix
- **Summary:** Fix NULL pointer dereference when DF functions are not
  initialized on soc24

Record: [drm/amdgpu] [fix] [NULL pointer dereference when df.funcs is
NULL in soc24_common_hw_init]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by:** Likun Gao (author)
- **Reviewed-by:** Hawking Zhang (AMD architect/maintainer for amdgpu)
- **Signed-off-by:** Alex Deucher (amdgpu subsystem maintainer)
- No Fixes: tag, no Cc: stable tag, no Reported-by (expected for manual
  review)

Record: Reviewed by Hawking Zhang (AMD subsystem architect) and merged
by Alex Deucher (amdgpu maintainer). Strong trust signal.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The body says: "If DF function not initialized, NULL pointer issue will
happen on soc24." This describes a concrete crash scenario: when
`adev->df.funcs` is NULL and code dereferences it to check `->hw_init`.

Record: [Bug: NULL pointer dereference] [Symptom: kernel oops/crash
during GPU hw_init or resume] [Root cause: missing NULL check before
dereferencing df.funcs pointer]

### Step 1.4: DETECT HIDDEN BUG FIXES
Not hidden - this is an explicit "fix" for a NULL pointer dereference.

Record: Not a hidden fix, explicitly labeled as a fix.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
- **Files:** 1 file changed (`drivers/gpu/drm/amd/amdgpu/soc24.c`)
- **Lines:** 1 line modified (replacing one condition with a guarded
  condition)
- **Function:** `soc24_common_hw_init()`
- **Scope:** Single-line surgical fix

Record: [soc24.c: 1 line changed in soc24_common_hw_init()] [Scope:
single-line surgical fix]

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Before:

```481:481:drivers/gpu/drm/amd/amdgpu/soc24.c
        if (adev->df.funcs->hw_init)
```

After:
```c
        if (adev->df.funcs && adev->df.funcs->hw_init)
```

The code was dereferencing `adev->df.funcs` (which can be NULL) to check
`hw_init`. The fix adds a NULL guard.

Record: [Before: unconditional dereference of df.funcs -> After: guarded
dereference with NULL check first]

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Category: NULL pointer dereference (d)**
- `adev->df.funcs` can be NULL if the DF IP version doesn't match any
  known version in `amdgpu_discovery.c`
- The code dereferences this NULL pointer to check `->hw_init`
- This causes a kernel oops

Record: [NULL pointer dereference] [df.funcs can be NULL when DF IP
version is unrecognized; the fix adds a standard guard consistent with
soc15.c patterns]

### Step 2.4: ASSESS THE FIX QUALITY
- Obviously correct: the pattern `if (ptr && ptr->member)` is idiomatic
  C null-guard
- Consistent: `soc15.c` already uses `if (adev->df.funcs &&
  adev->df.funcs->hw_init)` and `if (adev->df.funcs &&
  adev->df.funcs->sw_init)` - the exact same pattern
- Minimal: single condition addition, no behavior change when df.funcs
  is non-NULL
- Regression risk: zero - the only change is skipping the call when
  funcs is NULL (which would crash otherwise)

Record: [Obviously correct, minimal, zero regression risk. Matches
existing patterns in soc15.c]

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
The buggy line was introduced by commit `73048bda46c308` ("drm/amdgpu:
Fix atomics on GFX12") by David Belanger on 2024-06-10. This commit
added the DF hw_init call to soc24_common_hw_init but omitted the NULL
check for `adev->df.funcs`, unlike how soc15.c handles it.

Record: [Buggy code introduced by 73048bda46c308, present in v6.11+]

### Step 3.2: FOLLOW THE FIXES TAG
No Fixes: tag present (expected for review candidates).

Record: [No Fixes: tag, but the implicit fix target is 73048bda46c308]

### Step 3.3: CHECK FILE HISTORY
soc24.c was created by `98b912c50e449` (first in v6.11). The buggy
commit `73048bda46c308` was also added in v6.11. The file has had ~20
subsequent commits (refactoring handle pointers, etc.), but none touched
this specific df.funcs line.

Record: [Standalone fix, no prerequisites beyond the original buggy
commit]

### Step 3.4: CHECK THE AUTHOR
Likun Gao is a regular AMD GPU contributor with multiple recent commits
to the amdgpu subsystem. The reviewer (Hawking Zhang) is the original
soc24.c creator and AMD architect.

Record: [Author is a regular AMD contributor; reviewer is the subsystem
architect]

### Step 3.5: DEPENDENCIES
This fix has no dependencies. It simply adds a NULL check guard to an
existing conditional. It will apply to any tree that contains commit
`73048bda46c308`.

Record: [No dependencies, standalone fix]

---

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1: PATCH DISCUSSION
Found the original submission at
[spinics](https://www.spinics.net/lists/amd-gfx/msg138858.html).
Submitted by Alex Deucher on March 6, 2026. No objections or NAKs
visible. It was part of a batch of AMD GPU fixes.

Record: [Found submission on amd-gfx list, no objections, submitted in a
batch of fixes by the maintainer]

### Step 4.2: REVIEWERS
Reviewed by Hawking Zhang (AMD architect), signed off by Alex Deucher
(subsystem maintainer). Both are the top-level amdgpu maintainers.

Record: [Reviewed and merged by subsystem maintainers]

### Step 4.3-4.5: BUG REPORT / RELATED PATCHES / STABLE HISTORY
No syzbot report, no explicit bug report URL. This appears to be an
internally-discovered issue at AMD.

Record: [Internal AMD finding, no external bug report]

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.2: KEY FUNCTIONS AND CALLERS
`soc24_common_hw_init()` is called:
1. During GPU initialization via the `amd_ip_funcs` table (line 588:
   `.hw_init = soc24_common_hw_init`)
2. During resume via `soc24_common_resume()` (line 524-527)

Both are common execution paths for any system with soc24 hardware.

### Step 5.3-5.4: WHY df.funcs CAN BE NULL
In `amdgpu_discovery.c`, `adev->df.funcs` is set in a switch on
`DF_HWIP` version. The default case is `break` (no assignment). If a
soc24 device has a DF IP version not in the list, `df.funcs` remains
NULL. This is the exact trigger.

### Step 5.5: SIMILAR PATTERNS
Verified: `soc15.c` consistently uses the guarded pattern:
- Line 1253: `if (adev->df.funcs && adev->df.funcs->sw_init)`
- Line 1264: `if (adev->df.funcs && adev->df.funcs->sw_fini)`
- Line 1498: `if (adev->df.funcs &&
  adev->df.funcs->get_clockgating_state)`
- `gmc_v9_0.c` also guards with `if (adev->df.funcs && ...)`

soc24.c is the ONLY file missing this guard.

Record: [All other callers guard df.funcs with NULL check; soc24.c is
the sole exception]

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: BUGGY CODE IN STABLE TREES
- `soc24.c` first appeared in v6.11
- The buggy commit `73048bda46c308` is in v6.11+
- Therefore the bug exists in stable trees: **6.11.y, 6.12.y, 7.0.y**
- Not present in 6.6.y or earlier (soc24.c doesn't exist there)

Record: [Bug exists in 6.11.y, 6.12.y, 7.0.y]

### Step 6.2: BACKPORT COMPLICATIONS
The fix is a single-line change. No conflicting refactoring has touched
this specific line. Clean apply expected.

Record: [Expected clean apply to all affected stable trees]

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
- **Subsystem:** GPU driver (drm/amdgpu) - IMPORTANT
- AMD GPUs are extremely common in desktop and laptop systems
- soc24 corresponds to RDNA4 generation (GC 12.0.x) - recent and
  actively shipping hardware

Record: [drm/amdgpu] [IMPORTANT - affects users of recent AMD GPUs]

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
All users with soc24 (RDNA4) AMD GPU hardware where the DF IP version
doesn't match a listed version in discovery.

### Step 8.2: TRIGGER CONDITIONS
The crash triggers during:
- GPU hardware initialization (every boot)
- GPU resume from suspend (every suspend/resume cycle)
These are unavoidable common paths.

### Step 8.3: FAILURE MODE SEVERITY
**CRITICAL** - NULL pointer dereference causes a kernel oops, crashing
the system during boot or resume. The GPU driver is essential for
display output.

### Step 8.4: RISK-BENEFIT RATIO
- **Benefit:** Prevents kernel oops on boot/resume for soc24 users -
  VERY HIGH
- **Risk:** 1-line addition of a NULL check, zero chance of regression -
  VERY LOW
- **Ratio:** Extremely favorable

Record: [Benefit: VERY HIGH (prevents crash), Risk: VERY LOW (1-line
NULL guard)]

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: EVIDENCE COMPILATION

**FOR backporting:**
- Fixes a NULL pointer dereference (kernel oops/crash)
- Affects GPU init and resume paths (common, unavoidable paths)
- Single-line fix, obviously correct
- Matches existing defensive patterns in soc15.c, gmc_v9_0.c,
  amdgpu_ras.c
- Reviewed by AMD architect (Hawking Zhang), merged by subsystem
  maintainer (Alex Deucher)
- Zero regression risk
- Affects actively-shipping hardware (RDNA4)

**AGAINST backporting:**
- None identified

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** - standard NULL guard, matches
   existing patterns, reviewed by maintainers
2. Fixes a real bug? **YES** - NULL pointer dereference → kernel oops
3. Important issue? **YES** - system crash during GPU init/resume
   (CRITICAL)
4. Small and contained? **YES** - 1 line changed in 1 file
5. No new features or APIs? **YES** - purely defensive check
6. Can apply to stable? **YES** - clean apply expected for 6.11.y+

### Step 9.3: EXCEPTION CATEGORIES
Not an exception case; this is a standard bug fix that meets all normal
criteria.

### Step 9.4: DECISION
This is a textbook stable backport candidate: a one-line NULL pointer
check that prevents a kernel oops during GPU initialization and resume
on recent AMD hardware.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by: Hawking Zhang, SOB: Likun Gao,
  Alex Deucher
- [Phase 2] Diff analysis: 1 line changed in soc24_common_hw_init(),
  adds `adev->df.funcs &&` guard
- [Phase 3] git blame: buggy code introduced in commit 73048bda46c308
  (v6.11), "Fix atomics on GFX12"
- [Phase 3] git merge-base: confirmed 73048bda46c308 is in v6.11+,
  soc24.c first added in v6.11
- [Phase 4] Found original submission at spinics amd-gfx list, no NAKs
  or concerns
- [Phase 5] Grep for `adev->df.funcs`: soc15.c, gmc_v9_0.c, amdgpu_ras.c
  all use NULL guard; soc24.c is the only exception
- [Phase 5] amdgpu_discovery.c: df.funcs assignment has a `default:
  break` that leaves funcs NULL for unrecognized DF versions
- [Phase 5] soc24_common_resume() calls soc24_common_hw_init(),
  confirming crash on both init and resume
- [Phase 6] Bug exists in 6.11.y, 6.12.y, 7.0.y; not in 6.6.y or earlier
  (soc24.c not present)
- [Phase 8] Failure mode: NULL deref -> kernel oops during GPU
  init/resume, severity CRITICAL

**YES**

 drivers/gpu/drm/amd/amdgpu/soc24.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/soc24.c b/drivers/gpu/drm/amd/amdgpu/soc24.c
index ecb6c3fcfbd15..984262936545f 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc24.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc24.c
@@ -484,7 +484,7 @@ static int soc24_common_hw_init(struct amdgpu_ip_block *ip_block)
 	if (adev->nbio.funcs->remap_hdp_registers)
 		adev->nbio.funcs->remap_hdp_registers(adev);
 
-	if (adev->df.funcs->hw_init)
+	if (adev->df.funcs && adev->df.funcs->hw_init)
 		adev->df.funcs->hw_init(adev);
 
 	/* enable the doorbell aperture */
-- 
2.53.0