[PATCH AUTOSEL 7.0] drm/amdgpu: remove deadlocks from amdgpu_userq_pre_reset

[PATCH AUTOSEL 7.0] drm/amdgpu: remove deadlocks from amdgpu_userq_pre_reset

[Sasha Levin]

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

[ Upstream commit d5971c5c34303a00bf841a902ca00a703602c500 ]

The purpose of a GPU reset is to make sure that fence can be signaled
again and the signal and resume workers can make progress again.

So waiting for the resume worker or any fence in the GPU reset path is
just utterly nonsense.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Prike Liang <Prike.Liang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit fcd5f065eab46993af43442fd77ee8d9eb9c5bdf)
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Decision Summary
This should be backported for stable trees that contain
`amdgpu_userq_pre_reset()`. It removes two blocking waits from the GPU
reset path: `cancel_delayed_work_sync(&uqm->resume_work)` and
`amdgpu_userq_wait_for_last_fence()`, where the latter waits on
`dma_fence_wait_timeout(..., MAX_SCHEDULE_TIMEOUT)`. The reset path is
precisely what is supposed to let those fences/workers make progress, so
waiting there can deadlock GPU recovery.

The patch is one-function, one-file, no new API, and `git apply --check`
succeeds against this `7.0.y` checkout. Main concern: the review thread
confirms broader queue-state locking concerns remain, but those are pre-
existing and the accepted patch was explicitly scoped to removing the
obvious deadlock.

## Phase Walkthrough
Phase 1:
- Record 1.1: subsystem `drm/amdgpu`; action `remove`; intent is to
  remove deadlocks from `amdgpu_userq_pre_reset()`.
- Record 1.2: tags present: `Signed-off-by: Christian König`, `Reviewed-
  by: Prike Liang`, `Signed-off-by: Alex Deucher`; no `Fixes:`,
  `Reported-by:`, `Tested-by:`, `Acked-by:`, `Link:`, or `Cc: stable`.
- Record 1.3: commit body says GPU reset exists to allow fences and
  signal/resume workers to progress; waiting for resume worker or fences
  inside reset is wrong. Failure mode: reset can hang/deadlock.
- Record 1.4: not hidden; it is explicitly a deadlock fix.

Phase 2:
- Record 2.1: one file, `drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c`,
  `+12/-14`; only `amdgpu_userq_pre_reset()` changed; single-file
  surgical fix.
- Record 2.2: before, reset path canceled `resume_work` synchronously
  and waited for `last_fence` before unmapping mapped queues. After, it
  skips non-mapped queues and directly unmaps/marks hung/force-completes
  mapped queues.
- Record 2.3: bug category is deadlock/hang. Mechanism: reset path
  waited on work/fences that may require reset progress to complete.
- Record 2.4: fix is minimal. Regression risk is low-to-medium because
  queue-state locking is still called out by the TODO and review
  discussion, but no new API or broad behavior is added.

Phase 3:
- Record 3.1: `git blame` shows the reset function came from
  `290f46cf57265` (`drm/amdgpu: Implement user queue reset
  functionality`); current textual lines were later touched by
  `473f12f820956` and `dc21e39fd20c7` helper/signature cleanups. `git
  describe --contains 290f46cf...` points to `v6.19-rc1`, so older
  stable trees before v6.19 likely do not contain this exact code.
- Record 3.2: no `Fixes:` tag, so no Fixes target to follow.
- Record 3.3: recent file history shows active userq work and related
  reset/fence changes; this patch applies standalone to current `7.0.y`.
- Record 3.4: `MAINTAINERS` lists Christian König and Alex Deucher as
  AMDGPU DRM maintainers; author/committer are subsystem maintainers.
- Record 3.5: no compile dependency found; patch is part of an 11-patch
  series but applies cleanly by itself.

Phase 4:
- Record 4.1: `b4 dig` failed because the commit object is absent
  locally. Fallback found the original patch at
  `lists.freedesktop.org/archives/amd-gfx/2026-April/143199.html`;
  committed version matches the patch content with `Reviewed-by` added.
- Record 4.2: `b4 -w` failed; lore thread shows Alex Deucher, Prike
  Liang, Sunil Khatri, and `amd-gfx` were involved.
- Record 4.3: no external bug report or syzbot link found.
- Record 4.4: series context exists (`[PATCH 02/11]`), with later
  userq/fence/reset cleanups, but no hard prerequisite was identified
  for this specific deadlock removal.
- Record 4.5: web search did not find stable-list discussion for this
  exact patch.

Phase 5:
- Record 5.1: modified function: `amdgpu_userq_pre_reset()`.
- Record 5.2: callers: local search shows only
  `amdgpu_device_halt_activities()`, called from
  `amdgpu_device_gpu_recover()` and PCI error handling.
- Record 5.3: affected callees include `userq_funcs->unmap()` and
  `amdgpu_userq_fence_driver_force_completion()`; removed callees
  include `cancel_delayed_work_sync()` and
  `amdgpu_userq_wait_for_last_fence()`.
- Record 5.4: reachable through AMDGPU recovery paths, including job
  timeout/GPU recovery paths; exact unprivileged trigger policy was not
  fully verified.
- Record 5.5: similar wait/cancel patterns remain in non-reset paths
  such as destroy/suspend/eviction, but the reset-path instance is the
  one fixed here.

Phase 6:
- Record 6.1: buggy code exists in this `7.0.y` tree and appears
  introduced for `v6.19-rc1`; likely relevant to v6.19+ stable trees
  containing userq reset support.
- Record 6.2: `git apply --check` succeeds against this checkout, so
  current `7.0.y` backport difficulty is clean.
- Record 6.3: no exact related stable replacement fix found locally or
  in web stable search.

Phase 7:
- Record 7.1: subsystem is AMDGPU DRM driver; criticality is IMPORTANT,
  driver-specific but for widely used GPU hardware.
- Record 7.2: subsystem/file is active; recent history contains many
  userq reset/fence fixes and refactors.

Phase 8:
- Record 8.1: affected users are AMDGPU users with user queues enabled
  who hit GPU reset/recovery.
- Record 8.2: trigger is GPU reset while user queues have pending resume
  work or unsignaled fences; commonality depends on userq usage and GPU
  hangs.
- Record 8.3: failure mode is GPU reset deadlock/hang; severity HIGH to
  CRITICAL because recovery can stall.
- Record 8.4: benefit is high for affected systems; risk is low-to-
  medium due small scope but reset-path concurrency sensitivity. Ratio
  favors backport.

Phase 9:
- Record 9.1 FOR: fixes deadlock, reset-path hang, small one-function
  diff, maintainer-authored, reviewed, applies cleanly. AGAINST: no
  reported user bug, no stable tag, part of a larger userq series,
  residual queue-state locking TODO. UNRESOLVED: no runtime
  reproduction/build, exact applicability to every active stable branch
  not verified.
- Record 9.2 stable rules: obviously correct enough by code and
  maintainer review: yes; fixes real bug: yes, deadlock; important
  issue: yes, recovery hang; small/contained: yes; no new API/features:
  yes; can apply to current stable tree: yes.
- Record 9.3 exception category: none.
- Record 9.4 decision: backport to stable trees containing this userq
  reset code.

## Verification
- [Phase 1] Parsed GitHub patch and lore message: confirmed subject,
  body, tags, and lack of `Fixes`/`Cc stable`.
- [Phase 2] Compared diff: confirmed one-file `+12/-14` change removing
  `cancel_delayed_work_sync()` and `amdgpu_userq_wait_for_last_fence()`.
- [Phase 3] `git blame`: confirmed reset code origin/refactor history
  around `amdgpu_userq_pre_reset()`.
- [Phase 3] `git describe --contains`: confirmed introduction is in the
  v6.19 era.
- [Phase 3] `MAINTAINERS`: confirmed Christian König and Alex Deucher
  maintain AMDGPU DRM.
- [Phase 4] `b4 dig -c/-a/-w`: failed because commit object is not in
  this checkout.
- [Phase 4] WebFetch GitHub patch and freedesktop lore: confirmed
  original patch, review discussion, and `Reviewed-by: Prike Liang`.
- [Phase 5] `rg` and file reads: confirmed caller path through
  `amdgpu_device_halt_activities()` and `amdgpu_device_gpu_recover()`.
- [Phase 6] `git apply --check`: confirmed clean application to current
  `7.0.y`.
- UNVERIFIED: no kernel build or runtime reproduction was performed;
  exact applicability to all non-`7.0.y` stable trees was not fully
  checked.

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 26 +++++++++++------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
index 0a1b93259887a..6f49ba3bd0394 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
@@ -1583,23 +1583,21 @@ void amdgpu_userq_pre_reset(struct amdgpu_device *adev)
 {
 	const struct amdgpu_userq_funcs *userq_funcs;
 	struct amdgpu_usermode_queue *queue;
-	struct amdgpu_userq_mgr *uqm;
 	unsigned long queue_id;
 
+	/* TODO: We probably need a new lock for the queue state */
 	xa_for_each(&adev->userq_doorbell_xa, queue_id, queue) {
-		uqm = queue->userq_mgr;
-		cancel_delayed_work_sync(&uqm->resume_work);
-		if (queue->state == AMDGPU_USERQ_STATE_MAPPED) {
-			amdgpu_userq_wait_for_last_fence(queue);
-			userq_funcs = adev->userq_funcs[queue->queue_type];
-			userq_funcs->unmap(queue);
-			/* just mark all queues as hung at this point.
-			 * if unmap succeeds, we could map again
-			 * in amdgpu_userq_post_reset() if vram is not lost
-			 */
-			queue->state = AMDGPU_USERQ_STATE_HUNG;
-			amdgpu_userq_fence_driver_force_completion(queue);
-		}
+		if (queue->state != AMDGPU_USERQ_STATE_MAPPED)
+			continue;
+
+		userq_funcs = adev->userq_funcs[queue->queue_type];
+		userq_funcs->unmap(queue);
+		/* just mark all queues as hung at this point.
+		 * if unmap succeeds, we could map again
+		 * in amdgpu_userq_post_reset() if vram is not lost
+		 */
+		queue->state = AMDGPU_USERQ_STATE_HUNG;
+		amdgpu_userq_fence_driver_force_completion(queue);
 	}
 }
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] drm/panel: feiyang-fy07024di26a30d: return display-on error

[Sasha Levin]

From: Christian Van <cvan20191@gmail.com>

[ Upstream commit c67e8787f6743101c90c7a9c4bb7cf6f1f739f83 ]

mipi_dsi_dcs_set_display_on() returns an error code, but feiyang_enable()
currently ignores it and always reports success.

Return the DCS command result so callers can observe enable failures.

Signed-off-by: Christian Van <cvan20191@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260425053948.117714-1-cvan20191@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `drm/panel`, action verb `return`, summary:
`feiyang-fy07024di26a30d` should propagate the MIPI DSI display-on
command error instead of reporting success.

Step 1.2 Record: tags verified:
- `Signed-off-by: Christian Van <cvan20191@gmail.com>`
- `Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>`
- `Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>`
- `Link:
  https://patch.msgid.link/20260425053948.117714-1-cvan20191@gmail.com`
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Cc: stable`, syzbot, or
sanitizer tags were present.

Step 1.3 Record: the body says `mipi_dsi_dcs_set_display_on()` returns
an error but `feiyang_enable()` ignores it and always returns success.
Verified in `drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c`.
Symptom: DRM panel core cannot observe a failed display-on command and
may continue the enable sequence as if the panel enabled successfully.
No user report, stack trace, or affected-version statement was found.

Step 1.4 Record: yes, this is a hidden bug fix: it fixes ignored error
handling in a panel enable path. It is not cleanup or refactoring.

## Phase 2: Diff Analysis
Step 2.1 Record: one file changed, `drivers/gpu/drm/panel/panel-feiyang-
fy07024di26a30d.c`; 1 insertion, 3 deletions. Modified function:
`feiyang_enable()`. Scope: single-file surgical driver fix.

Step 2.2 Record: before, `feiyang_enable()` called
`mipi_dsi_dcs_set_display_on(ctx->dsi)` and always returned `0`. After,
it returns the DCS command result directly. Affected path: normal panel
enable path, after the 200 ms enable delay.

Step 2.3 Record: bug category is logic/error-propagation correctness.
The broken mechanism was an ignored negative return from
`mipi_dsi_dcs_set_display_on()`. Verified that
`mipi_dsi_dcs_set_display_on()` returns `0` on success or a negative
error code on failure.

Step 2.4 Record: fix quality is high: minimal, obviously correct, no new
API, no locking, no data structure change. Regression risk is very low;
the only behavior change is that a real display-on failure prevents
`drm_panel_enable()` from marking the panel enabled and enabling
backlight/followers.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the ignored return was introduced
with the original driver commit
`69dc678abc2b9d36ff005413ca6e9edabe4c369a` (`drm/panel: Add Feiyang
FY07024DI26A30-D MIPI-DSI LCD panel`), first contained in `v5.2-rc1`.

Step 3.2 Record: no `Fixes:` tag was present, so there was no tag to
follow. I inspected the original driver commit anyway; it added the
driver and already ignored this display-on return.

Step 3.3 Record: recent file history shows mostly unrelated panel API
conversions and cleanup. The candidate patch is standalone and only
needs the existing `feiyang_enable()` and
`mipi_dsi_dcs_set_display_on()` code.

Step 3.4 Record: no other `Christian Van` commits under
`drivers/gpu/drm/panel` were found in checked `master` or `graphics-
next`. Neil Armstrong is listed as DRM panel maintainer in `MAINTAINERS`
and reviewed/applied the patch.

Step 3.5 Record: no dependencies found. The patch applies directly to
`v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and `v7.0`; `v5.4`
contains the buggy code but needs a trivial context backport.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c c67e8787f6743101c90c7a9c4bb7cf6f1f739f83`
found the original submission at
`https://patch.msgid.link/20260425053948.117714-1-cvan20191@gmail.com`.
`b4 dig -a` found only v1, so the committed version is the only revision
found.

Step 4.2 Record: `b4 dig -w` showed the original recipients included
Christian Van, Jagan Teki, Neil Armstrong, Jessica Zhang, Maarten
Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie, Simona
Vetter, `dri-devel`, and `linux-kernel`. Neil Armstrong reviewed it and
later applied it to `drm-misc-fixes`.

Step 4.3 Record: no `Reported-by` or bug-report link exists. WebFetch
for lore URLs was blocked by Anubis, but `b4 mbox` fetched the thread
successfully. The thread contained Neil’s `Reviewed-by` reply and an
applied notice.

Step 4.4 Record: no multi-patch series found; this is a standalone
1-patch series.

Step 4.5 Record: WebFetch searches of `lore.kernel.org/stable` were
blocked by Anubis. Local pending/stable candidate branches searched did
not show this patch already present.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified function: `feiyang_enable()`.

Step 5.2 Record: `feiyang_enable()` is installed as `.enable` in
`feiyang_funcs`. `drm_panel_enable()` calls
`panel->funcs->enable(panel)` and checks negative returns. Multiple DRM
bridge/host drivers call `drm_panel_enable()`.

Step 5.3 Record: key callees are `msleep(200)` and
`mipi_dsi_dcs_set_display_on(ctx->dsi)`. The latter calls
`mipi_dsi_dcs_write()` and returns a negative error on write failure.

Step 5.4 Record: reachable through DRM panel enable paths during display
modeset/enable for systems using this panel. This is driver/hardware-
specific, not universal. No in-tree DTS user of
`feiyang,fy07024di26a30d` was found beyond the binding example and
driver match table.

Step 5.5 Record: many other panel drivers already check and return or
handle `mipi_dsi_dcs_set_display_on()` errors, confirming this driver
was an outlier.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: buggy code exists in `v5.4`, `v5.10`, `v5.15`, `v6.1`,
`v6.6`, `v6.12`, `v6.19`, and `v7.0`. The driver was introduced for
`v5.2-rc1`, so all active stable trees at or after that point likely
contain it.

Step 6.2 Record: expected backport difficulty is clean for `v5.10+`
based on apply checks. `v5.4` failed direct apply due to context drift
but contains the same ignored call and should need only a trivial one-
function backport.

Step 6.3 Record: no related stable-side fix for this same issue was
found in the checked stable/pending branches.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: subsystem is DRM panel driver, criticality
`PERIPHERAL`/driver-specific. It affects users of Feiyang
FY07024DI26A30-D MIPI-DSI panels.

Step 7.2 Record: DRM panel is maintained and active. The file has had
several API-conversion commits since introduction, but this fix is not
dependent on those conversions for `v5.10+`.

## Phase 8: Impact And Risk Assessment
Step 8.1 Record: affected population is driver-specific/config-specific:
kernels with `CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D` and hardware
described with `feiyang,fy07024di26a30d`.

Step 8.2 Record: trigger is a failure of the DSI `SET_DISPLAY_ON`
command during panel enable. I did not verify a specific real-world
reporter, so frequency is unverified. It is not shown to be
unprivileged-user-triggerable.

Step 8.3 Record: failure mode is user-visible display enable
misreporting: before the patch, the panel core could treat the panel as
enabled despite the failed display-on command. Severity: `MEDIUM` for
affected hardware, because it can leave display/backlight state wrong,
but no crash, memory corruption, deadlock, or security issue was
verified.

Step 8.4 Record: benefit is moderate for affected hardware; risk is very
low because the patch only returns an existing error code from a
function that already has an `int` return type.

## Phase 9: Final Synthesis
Step 9.1 Record:
Evidence for backporting: real ignored-error bug; affects display enable
correctness; original buggy code dates to `v5.2-rc1`; one-line surgical
fix; maintainer reviewed/applied to `drm-misc-fixes`; clean apply to
`v5.10+`; no new API or feature.
Evidence against backporting: no user report, crash, security issue,
data corruption, syzbot report, or `Fixes:` tag; affected population is
limited to one panel driver; `v5.4` needs a trivial manual backport.
Unresolved: actual field frequency of DSI display-on failures was not
verified.

Step 9.2 Record:
1. Obviously correct and tested? Correct by inspection; reviewed by DRM
   panel maintainer. No explicit `Tested-by`.
2. Fixes a real bug? Yes, ignored negative return from a hardware
   command.
3. Important issue? Moderate: display enable state correctness for
   affected hardware, not a critical kernel-wide failure.
4. Small and contained? Yes, one function, one file, 1 insertion/3
   deletions.
5. No new features/APIs? Yes.
6. Can apply to stable? Yes for `v5.10+`; trivial backport needed for
   `v5.4`.

Step 9.3 Record: no automatic exception category applies; this is not a
device ID, quirk, DT, build, or documentation patch.

Step 9.4 Record: I recommend backporting. Although the impact is driver-
specific and not a crash-class bug, the fix is a genuine hardware enable
error propagation fix, very small, maintainer-reviewed, and low risk.
Stable users with this panel should not have the panel core mark the
panel enabled after the display-on command failed.

## Verification
- Phase 1: Parsed commit `c67e8787f6743101c90c7a9c4bb7cf6f1f739f83` with
  `git show`; confirmed subject, body, trailers, and diff.
- Phase 2: Read `panel-feiyang-fy07024di26a30d.c`; confirmed old
  `feiyang_enable()` ignored `mipi_dsi_dcs_set_display_on()` and
  returned `0`.
- Phase 2: Read `drm_mipi_dsi.c`; confirmed
  `mipi_dsi_dcs_set_display_on()` returns a negative error on failure.
- Phase 3: Ran `git blame -L 94,104`; confirmed buggy lines came from
  `69dc678abc2b9d`.
- Phase 3: Ran `git describe --contains 69dc678abc2b9d`; confirmed first
  containing version `v5.2-rc1`.
- Phase 3: Inspected original commit `69dc678abc2b9d`; confirmed the
  ignored return existed from driver introduction.
- Phase 4: Ran `b4 dig -c`, `b4 dig -a`, and `b4 dig -w`; confirmed one
  v1 patch, original lore URL, and recipient list.
- Phase 4: Ran `b4 mbox`; confirmed Neil Armstrong reviewed and applied
  it to `drm-misc-fixes`.
- Phase 4: WebFetch lore and stable searches were blocked by Anubis;
  this limitation did not drive the final decision.
- Phase 5: Read `drm_panel.c`; confirmed `drm_panel_enable()` checks
  negative `.enable` return and skips enabled/backlight/follower path on
  failure.
- Phase 5: Searched for `feiyang_enable`; confirmed it is used via
  `.enable = feiyang_enable`.
- Phase 5: Searched panel drivers for `mipi_dsi_dcs_set_display_on()`;
  confirmed many peers handle its return.
- Phase 6: Used `git grep` against stable tags; confirmed the ignored
  call exists in `v5.4`, `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.19`, and
  `v7.0`.
- Phase 6: Apply-checked the patch in detached worktrees; clean for
  `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and `v7.0`; failed
  direct apply on `v5.4` due to context only.
- Phase 7: Checked `MAINTAINERS`; confirmed Neil Armstrong maintains DRM
  panel drivers.
- Phase 8: Checked Kconfig and compatible strings; confirmed impact is
  limited to the Feiyang panel driver/config and no in-tree board DTS
  use was found.
- UNVERIFIED: no actual user report or frequency of display-on command
  failures was found.

**YES**

 drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
index 4f8d6d8c07e4d..dbdb7e3cb7b62 100644
--- a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -98,9 +98,7 @@ static int feiyang_enable(struct drm_panel *panel)
 	/* T12 (video & logic signal rise + backlight rise) T12 >= 200ms */
 	msleep(200);
 
-	mipi_dsi_dcs_set_display_on(ctx->dsi);
-
-	return 0;
+	return mipi_dsi_dcs_set_display_on(ctx->dsi);
 }
 
 static int feiyang_disable(struct drm_panel *panel)
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] fbdev: ipu-v3: clean up kernel-doc warnings

[Sasha Levin]

From: Randy Dunlap <rdunlap@infradead.org>

[ Upstream commit f1fb23a0a0fcbdb66672da51d7d63a259f6396ca ]

Correct all kernel-doc warnings:
- fix a typedef kernel-doc comment
- mark a list_head as private
- use Returns: for function return values

Warning: include/video/imx-ipu-image-convert.h:31 struct member 'list' not
 described in 'ipu_image_convert_run'
Warning: include/video/imx-ipu-image-convert.h:40 function parameter
 'ipu_image_convert_cb_t' not described in 'void'
Warning: include/video/imx-ipu-image-convert.h:40 expecting prototype for
 ipu_image_convert_cb_t(). Prototype was for void() instead
Warning: include/video/imx-ipu-image-convert.h:66 No description found for
 return value of 'ipu_image_convert_verify'
Warning: include/video/imx-ipu-image-convert.h:90 No description found for
 return value of 'ipu_image_convert_prepare'
Warning: include/video/imx-ipu-image-convert.h:125 No description found for
 return value of 'ipu_image_convert_queue'
Warning: include/video/imx-ipu-image-convert.h:163 No description found for
 return value of 'ipu_image_convert'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `fbdev: ipu-v3`; action verb `clean up`;
intent is to correct kernel-doc warnings in `include/video/imx-ipu-
image-convert.h`.

Step 1.2 Record: tags in committed message are `Signed-off-by: Randy
Dunlap <rdunlap@infradead.org>`, `Reviewed-by: Philipp Zabel
<p.zabel@pengutronix.de>`, and `Signed-off-by: Helge Deller
<deller@gmx.de>`. No `Fixes:`, `Reported-by:`, `Tested-by:`, `Acked-
by:`, `Link:`, or `Cc: stable@vger.kernel.org` tag is present in the
committed message.

Step 1.3 Record: the described problem is seven kernel-doc warnings: one
undocumented/private list member, malformed typedef documentation, and
missing `Returns:` sections. The visible symptom is documentation
tooling warnings, not a runtime crash, hang, data corruption, or
security issue. No affected kernel version is stated. Root cause is
incorrect kernel-doc comment syntax.

Step 1.4 Record: this is not a hidden runtime bug fix. The body and diff
both show a documentation/comment-only cleanup.

## Phase 2: Diff Analysis
Step 2.1 Record: one file changed: `include/video/imx-ipu-image-
convert.h`, 11 insertions and 5 deletions. Modified documentation covers
`struct ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`. Scope is single-
file, header-only, surgical.

Step 2.2 Record: hunk behavior:
- `struct ipu_image_convert_run`: before, `list` was documented neither
  as a member nor private; after, `/* private: */` tells kernel-doc to
  ignore it as an API member.
- `ipu_image_convert_cb_t`: before, kernel-doc treated the typedef
  comment as a function prototype mismatch; after, it is marked as a
  typedef comment.
- Return docs: before, several returns were plain prose or missing;
  after, they use kernel-doc `Returns:` syntax.
- `ipu_image_convert_prepare()`: before, the V4L2 usage note followed
  the return prose; after, the return section is last and formatted for
  kernel-doc.

Step 2.3 Record: bug category is documentation/kernel-doc warning
cleanup. No error-path, synchronization, refcount, memory-safety,
initialization, type, logic, or hardware workaround change exists.

Step 2.4 Record: fix quality is high for the stated documentation issue:
small, obviously correct kernel-doc syntax changes. Runtime regression
risk is effectively zero because no C declarations, types, function
bodies, data layout, or APIs are changed. Documentation rendering risk
is very low.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the affected header comments and
declarations came from `cd98e85a6b786d` by Steve Longerbeam, dated
2016-09-17. `git describe --contains cd98e85a6b786d` reports it as
present by `v4.9-rc1~41^2~24^2`.

Step 3.2 Record: no `Fixes:` tag is present, so there is no tagged
introducing commit to follow. Blame identifies `cd98e85a6b786d` as the
source of the documented preimage; `git show` confirms that commit added
queued IPU image conversion support and the API documentation.

Step 3.3 Record: recent local history for the file shows `96e9d754b35e8`
removing unused `ipu_image_convert_*` functions, `c942fddf8793b` adding
SPDX boilerplate conversion, and `cd98e85a6b786d` adding the header/API.
No prerequisite commit is needed for this documentation-only patch.

Step 3.4 Record: `git log --author='Randy Dunlap'` under fbdev/include
areas shows Randy has related cleanup/documentation work such as `fbdev:
hgafb: fix kernel-doc comments` and `fbdev: fbmon: fix function name in
kernel-doc`. The patch was reviewed by Philipp Zabel and committed by
Helge Deller, verified from the commit and lore thread.

Step 3.5 Record: no dependencies found. The diff changes only comments
and applies locally with `git apply --check`.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`
failed to find a lore match by patch-id, author/subject, or in-body
From. External fetch found the v3 discussion at
`https://yhbt.net/lore/dri-
devel/20260427183236.656902-1-rdunlap@infradead.org/T/`. The v3 thread
has Helge Deller replying “applied to fbdev git tree.” Web search/fetch
also found v2 and a v2 ping. No NAKs or objections were found.

Step 4.2 Record: `b4 dig -w` also failed for the same reason. The v3
lore mirror shows recipients included `dri-devel`, Philipp Zabel, DRM
maintainers, `imx`, `linux-arm-kernel`, Helge Deller, and `linux-fbdev`.

Step 4.3 Record: no `Reported-by:` or bug-report `Link:` tags exist. No
external crash/security bug report applies.

Step 4.4 Record: this is a standalone one-patch documentation cleanup.
v2 added the reviewed-by and updated Cc list; v3 rebased and resent.

Step 4.5 Record: direct `lore.kernel.org/stable` fetch was blocked by
Anubis. Web search for the exact subject plus `stable` found patch-
thread results but no stable-specific discussion or stable nomination.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified documented symbols are
`ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`.

Step 5.2 Record: `rg` found callers in `drivers/staging/media/imx/imx-
media-csc-scaler.c` for `ipu_image_convert_abort()`,
`ipu_image_convert_queue()`, `ipu_image_convert_adjust()`,
`ipu_image_convert_unprepare()`, and `ipu_image_convert_prepare()`.
Runtime callers are unaffected because only comments changed.

Step 5.3 Record: reading `drivers/gpu/ipu-v3/ipu-image-convert.c`
confirms the documented functions perform image format
adjustment/verification, context allocation, queueing, abort/unprepare,
and single conversion setup. None of those function bodies are touched.

Step 5.4 Record: runtime path is reachable through IPU image conversion
users, but the patch changes no runtime path. The affected path for the
fix is kernel-doc/documentation generation.

Step 5.5 Record: no related same-header kernel-doc fix was found by `git
log --grep='kernel-doc' -- include/video/imx-ipu-image-convert.h`.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: version tags `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
`v6.15`, `v6.16`, and `v6.17` all contain `include/video/imx-ipu-image-
convert.h` with the old kernel-doc text. The API was introduced before
`v4.9-rc1`, so active stable trees checked contain the documentation
issue.

Step 6.2 Record: expected backport difficulty is clean or minor. `git
apply --check` succeeds against the current local tree, and the checked
stable tags contain representative preimage lines. Full per-stable
worktree application was not run.

Step 6.3 Record: no related stable fix for this header was found in
local `git log --grep` searches.

## Phase 7: Subsystem Context
Step 7.1 Record: subsystem is fbdev/gpu IPU-v3 image conversion
documentation in an include header. Runtime criticality is
peripheral/driver-specific; documentation-build criticality is low.

Step 7.2 Record: local subsystem history shows ongoing cleanup/removal
activity in `drivers/gpu/ipu-v3` and the header, including unused-
function removals and treewide cleanup. This patch is not part of a
required functional series.

## Phase 8: Impact And Risk
Step 8.1 Record: affected population is kernel documentation builders,
maintainers, and users consuming generated kernel-doc. Runtime users of
IPU-v3 are not affected by behavior.

Step 8.2 Record: trigger is running kernel-doc/documentation tooling
over this header. It is not triggered by boot, device probe, syscalls,
or ordinary runtime use. Unprivileged runtime trigger does not apply.

Step 8.3 Record: failure mode is documentation warnings only. Severity
is LOW. I did not verify any configuration where these warnings are
fatal, so that does not drive the decision.

Step 8.4 Record: benefit is low but real under the documentation-fix
exception: it makes stable documentation builds cleaner. Risk is
extremely low because only comments change. Risk/benefit is favorable if
stable accepts documentation corrections.

## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: pure documentation
correction, explicitly fixes listed kernel-doc warnings, tiny single-
file patch, reviewed by Philipp Zabel, applied by Helge Deller, old text
exists in active stable tags checked, and documentation/comment fixes
are an allowed stable exception. Evidence against: no runtime bug, no
crash/security/data-corruption impact, no stable nomination found, and
b4 could not match the thread. Unresolved: direct stable-lore search was
blocked; full apply checks on every stable branch were not run.

Step 9.2 Record:
1. Obviously correct and tested? Mostly yes for documentation syntax;
   reviewed and applied, but no `Tested-by`.
2. Fixes a real bug that affects users? Yes, a real kernel-doc warning
   issue; not a runtime bug.
3. Important issue? No runtime severity; LOW documentation-build
   severity.
4. Small and contained? Yes, 11 additions and 5 deletions in one header.
5. No new features or APIs? Yes, comments only.
6. Can apply to stable trees? Likely yes; local apply check passed and
   stable tags checked contain the preimage.

Step 9.3 Record: exception category applies: documentation/comment fix.
This is the main reason to accept despite lack of runtime impact.

Step 9.4 Decision: backporting is appropriate under the stable
documentation-fix exception. It is not a stability/security fix, but it
is a correct, reviewed, zero-runtime-risk cleanup of real kernel-doc
warnings in code present across active stable trees.

## Verification
- Phase 1: fetched and inspected committed metadata for
  `f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`; confirmed tags and
  message.
- Phase 2: `git show --stat --patch` confirmed one header, 11
  insertions, 5 deletions, comments only.
- Phase 3: `git blame` confirmed changed comment preimage from
  `cd98e85a6b786d`; `git describe --contains` placed it before
  `v4.9-rc1`; `git show cd98e85a6b786d` confirmed original API addition.
- Phase 3: `git log` on the header/subsystem found no prerequisite
  functional series.
- Phase 4: `b4 dig`, `b4 dig -a`, and `b4 dig -w` all failed to match;
  recorded as a tool limitation/failure.
- Phase 4: WebFetch of the v3 lore mirror confirmed the patch thread and
  Helge Deller’s applied reply; Spinics fetch confirmed v2 and a later
  ping.
- Phase 5: `rg` found runtime users; `ReadFile` of implementation
  confirmed function bodies exist but are not changed.
- Phase 6: tag checks confirmed the header and old doc text in `v5.10`,
  `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.15`, `v6.16`, and `v6.17`; `git
  apply --check` succeeded locally.
- Phase 8: severity/risk assessment is derived from the verified
  comments-only diff.
- UNVERIFIED: direct `lore.kernel.org/stable` search content was blocked
  by Anubis; no actual `make htmldocs` run was performed; full patch
  application against every individual stable branch was not performed.

**YES**

 include/video/imx-ipu-image-convert.h | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/include/video/imx-ipu-image-convert.h b/include/video/imx-ipu-image-convert.h
index 003b3927ede5c..6b77968a6a150 100644
--- a/include/video/imx-ipu-image-convert.h
+++ b/include/video/imx-ipu-image-convert.h
@@ -27,12 +27,13 @@ struct ipu_image_convert_run {
 
 	int status;
 
+	/* private: */
 	/* internal to image converter, callers don't touch */
 	struct list_head list;
 };
 
 /**
- * ipu_image_convert_cb_t - conversion callback function prototype
+ * typedef ipu_image_convert_cb_t - conversion callback function prototype
  *
  * @run:	the completed conversion run pointer
  * @ctx:	a private context pointer for the callback
@@ -60,7 +61,7 @@ void ipu_image_convert_adjust(struct ipu_image *in, struct ipu_image *out,
  * @out:	output image format
  * @rot_mode:	rotation mode
  *
- * Returns 0 if the formats and rotation mode meet IPU restrictions,
+ * Returns: 0 if the formats and rotation mode meet IPU restrictions,
  * -EINVAL otherwise.
  */
 int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
@@ -77,11 +78,11 @@ int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
  * @complete:	run completion callback
  * @complete_context:	a context pointer for the completion callback
  *
- * Returns an opaque conversion context pointer on success, error pointer
+ * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
+ *
+ * Returns: an opaque conversion context pointer on success, error pointer
  * on failure. The input/output formats and rotation mode must already meet
  * IPU retrictions.
- *
- * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
  */
 struct ipu_image_convert_ctx *
 ipu_image_convert_prepare(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
@@ -122,6 +123,8 @@ void ipu_image_convert_unprepare(struct ipu_image_convert_ctx *ctx);
  * In V4L2, drivers should call ipu_image_convert_queue() while
  * streaming to queue the conversion of a received input buffer.
  * For example mem2mem devices this would be called in .device_run.
+ *
+ * Returns: 0 on success or -errno on error.
  */
 int ipu_image_convert_queue(struct ipu_image_convert_run *run);
 
@@ -155,6 +158,9 @@ void ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx);
  * On successful return the caller can queue more run requests if needed, using
  * the prepared context in run->ctx. The caller is responsible for unpreparing
  * the context when no more conversion requests are needed.
+ *
+ * Returns: pointer to the created &struct ipu_image_convert_run that has
+ * been queued on success; an ERR_PTR(errno) on error.
  */
 struct ipu_image_convert_run *
 ipu_image_convert(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] drm/amd/ras: Fix CPER ring debugfs read overflow

[Sasha Levin]

From: Xiang Liu <xiang.liu@amd.com>

[ Upstream commit 6bbede02dc62a1021aeeae87ab243bd7a93c61d2 ]

The legacy CPER debugfs reader can reach the payload path without a
valid pointer snapshot. The remaining user byte count is also treated as
the ring occupancy in dwords, so reads past the header can copy more than
requested.

Take the CPER lock before sampling pointers. Resample rptr/wptr for
payload reads, bound the payload copy by available dwords and the
remaining user size, and advance the file position for each dword copied.

Signed-off-by: Xiang Liu <xiang.liu@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 1e40ef87ffdc291e05ccdade8b9170cc9c1c4249)
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Records

Step 1.1 Record: Subsystem `drm/amd/ras`; action verb `Fix`; claimed
intent is preventing CPER ring debugfs read overflow.

Step 1.2 Record: Tags present: `Signed-off-by: Xiang Liu
<xiang.liu@amd.com>`, `Reviewed-by: Tao Zhou <tao.zhou1@amd.com>`,
`Signed-off-by: Alex Deucher <alexander.deucher@amd.com>`, and a cherry-
pick line. No `Fixes:`, `Reported-by:`, `Tested-by:`, `Link:`, or `Cc:
stable`.

Step 1.3 Record: Commit body describes two concrete bugs: CPER payload
reads can proceed without a valid rptr/wptr snapshot, and byte `size` is
treated as dword ring occupancy, allowing copies beyond the requested
read count.

Step 1.4 Record: Not hidden; this is an explicit memory-safety/user-copy
bounds fix.

Step 2.1 Record: One file changed,
`drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c`; one function changed,
`amdgpu_debugfs_ring_read`; roughly +13/-? surgical single-function
change.

Step 2.2 Record: Before, CPER locking and pointer sampling happened only
when `*pos < 12`; payload-only reads used uninitialized `early[]`.
Before, payload loop copied one dword while decrementing `size` by one,
although `size` is bytes. After, CPER reads lock before sampling,
resample pointers for payload, compute available dwords separately, cap
reads by `size >> 2`, and advance `*pos`.

Step 2.3 Record: Bug category is memory safety / bounds correctness plus
synchronization. Mechanism: debugfs `read()` could return/copy more
bytes than requested and could use invalid CPER ring pointers on reads
starting past the header.

Step 2.4 Record: Fix quality is good: small, local, no API change.
Regression risk is low; it only changes CPER debugfs reads. Holding
`cper.ring_lock` for payload-only reads matches the existing intent to
serialize with `amdgpu_cper_ring_write`.

Step 3.1 Record: `git blame` shows the CPER payload reader came from
`5a1428242952f2` (`drm/amdgpu: read CPER ring via debugfs`), first
contained by `v6.15-rc1`; the partial CPER lock came from
`8652920d2c0024`.

Step 3.2 Record: No `Fixes:` tag to follow. I inspected the introducing
commits manually: `5a1428242952f2` added the affected CPER payload
reader; `8652920d2c0024` added the existing CPER ring mutex but only
around the header path.

Step 3.3 Record: Related history includes `4d614ce8ffd75` adding the
CPER ring buffer, `a6d9d192903ea` adding CPER writes, `d6f9bbce18762`
fixing CPER ring remaining-size computation, and `93c19634f72fb` fixing
a separate uniras CPER debugfs user-buffer overflow.

Step 3.4 Record: Xiang Liu has multiple AMDGPU/RAS CPER commits in this
area. Alex Deucher committed the patch per the commit tags and is the
AMDGPU maintainer path in local history.

Step 3.5 Record: Dependencies are the existing CPER ring/debugfs code.
The affected code exists in this v7.0.y checkout and in tags `v6.15`
through `v7.0`; it is absent from `v6.14` by pattern check.

Step 4.1 Record: `b4 dig -c 1e40ef...` failed because the commit object
is not present locally. Web searches did not find the exact target
subject/body; they found related AMDGPU CPER debugfs patches and the
uniras buffer-overflow bug report.

Step 4.2 Record: `b4 dig -w` also failed for the same reason. Commit
tags still show AMDGPU review by Tao Zhou and commit by Alex Deucher.

Step 4.3 Record: No direct bug report found for this exact patch.
Related Dan Carpenter report verified a similar CPER debugfs user-buffer
overflow in `amdgpu_ras_cper_debugfs_read`, not this legacy reader.

Step 4.4 Record: Related CPER series context verified on freedesktop
archives: CPER debugfs read and CPER mutex patches were part of a v2
AMDGPU CPER series.

Step 4.5 Record: No stable-specific discussion found for the exact
target terms.

Step 5.1 Record: Modified function: `amdgpu_debugfs_ring_read`.

Step 5.2 Record: Callers are debugfs file operations:
`amdgpu_debugfs_ring_fops.read` and, for SR-IOV,
`amdgpu_debugfs_virt_ring_read`, which calls `amdgpu_debugfs_ring_read`.

Step 5.3 Record: Key callees are `amdgpu_ring_get_rptr`,
`amdgpu_ring_get_wptr`, `put_user`, and CPER lock operations. CPER
writes use `amdgpu_cper_ring_write`, which takes the same
`cper.ring_lock`.

Step 5.4 Record: Reachability is via
`/sys/kernel/debug/dri/*/amdgpu_ring_cper`, created by
`amdgpu_debugfs_ring_init` for registered rings. `amdgpu_ring_init`
registers rings in `adev->rings`, and `amdgpu_debugfs_init` iterates
those rings.

Step 5.5 Record: Similar pattern found: separate uniras CPER reader
overflow fixed by `93c19634f72fb`.

Step 6.1 Record: Buggy legacy CPER debugfs reader exists in `v6.15`,
`v6.16`, `v6.17`, `v6.18`, `v6.19`, and `v7.0`; not found in `v6.14`.

Step 6.2 Record: Expected backport difficulty is low for trees
containing the CPER reader. I could not complete a meaningful `git apply
--check` because my hand-built check patch was malformed, but the
current file matches the relevant pre-fix logic.

Step 6.3 Record: Related uniras fix exists locally, but it does not fix
the legacy `amdgpu_debugfs_ring_read` CPER path.

Step 7.1 Record: Subsystem is AMDGPU DRM/RAS driver code. Criticality is
driver-specific, not core kernel-wide.

Step 7.2 Record: Subsystem is active; local history shows multiple
CPER/RAS changes around v6.15-v6.19.

Step 8.1 Record: Affected users are AMDGPU systems with CPER ring
enabled and debugfs CPER ring reads.

Step 8.2 Record: Trigger is reading the CPER ring debugfs file,
especially payload reads past the 12-byte header or small/count-limited
reads. Unprivileged triggerability depends on debugfs mount permissions
and was not verified.

Step 8.3 Record: Failure mode is user-copy beyond requested read size
and possible invalid ring indexing from missing pointer snapshot.
Severity: HIGH for memory-safety correctness, reduced by debugfs-only
exposure.

Step 8.4 Record: Benefit is meaningful for affected AMDGPU debugfs users
because it prevents incorrect user copies and invalid CPER ring reads.
Risk is low: small, contained, no feature/API change.

## Stable Rules

1. Obviously correct and tested: mostly yes by inspection and maintainer
   review tag; no explicit `Tested-by`.
2. Fixes a real bug: yes, byte count vs dword count and missing pointer
   snapshot are verified in the code.
3. Important issue: yes, memory-safety/user-copy overflow from a
   readable debugfs file.
4. Small and contained: yes, one function in one driver file.
5. No new features/APIs: yes.
6. Can apply to stable: yes for v6.15+ trees containing the CPER debugfs
   reader; not applicable to v6.14 and older.

## Verification

- Phase 1: Parsed provided commit message and tags; no `Fixes`,
  `Reported-by`, `Link`, or stable tag present.
- Phase 2: Compared provided diff with current
  `amdgpu_debugfs_ring_read` implementation; verified `size` is bytes
  and old CPER loop decrements it as dwords.
- Phase 3: Ran `git blame` on the affected function; identified
  `5a1428242952f2` and `8652920d2c0024`.
- Phase 3: Ran `git show` on related commits `4d614ce8ffd75`,
  `5a1428242952f2`, `8652920d2c0024`, `d6f9bbce18762`, `527e3d40339b`,
  `93c19634f72fb`, and `a91d91b600479`.
- Phase 4: Ran `b4 dig`; it failed because the target commit object is
  unavailable in this checkout.
- Phase 4: Web searched exact subject/body; no direct target lore found.
  Fetched related freedesktop CPER series and Dan Carpenter uniras
  overflow report.
- Phase 5: Used repo search/read to trace debugfs fops, ring debugfs
  creation, CPER writer locking, and ring registration.
- Phase 6: Checked tags `v6.14` through `v7.0`; verified affected code
  starts at `v6.15`.
- Phase 8: Verified debugfs exposure through
  `debugfs_create_file_size(..., 0444, ...)`; did not verify system
  mount permissions, so unprivileged exploitability remains unverified.

This is a small, well-scoped memory-safety fix for code present in
stable trees starting at v6.15. It should be backported to affected
stable trees.

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 29 +++++++++++++++++-------
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
index 4638a686a84e7..bebd72178cc13 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
@@ -572,8 +572,9 @@ static ssize_t amdgpu_debugfs_ring_read(struct file *f, char __user *buf,
 					size_t size, loff_t *pos)
 {
 	struct amdgpu_ring *ring = file_inode(f)->i_private;
-	uint32_t value, result, early[3];
+	u32 value, result, early[3] = { 0 };
 	uint64_t p;
+	u32 avail_dw, start_dw, read_dw;
 	loff_t i;
 	int r;
 
@@ -585,10 +586,10 @@ static ssize_t amdgpu_debugfs_ring_read(struct file *f, char __user *buf,
 
 	result = 0;
 
-	if (*pos < 12) {
-		if (ring->funcs->type == AMDGPU_RING_TYPE_CPER)
-			mutex_lock(&ring->adev->cper.ring_lock);
+	if (ring->funcs->type == AMDGPU_RING_TYPE_CPER)
+		mutex_lock(&ring->adev->cper.ring_lock);
 
+	if (*pos < 12) {
 		early[0] = amdgpu_ring_get_rptr(ring) & ring->buf_mask;
 		early[1] = amdgpu_ring_get_wptr(ring) & ring->buf_mask;
 		early[2] = ring->wptr & ring->buf_mask;
@@ -620,13 +621,24 @@ static ssize_t amdgpu_debugfs_ring_read(struct file *f, char __user *buf,
 			*pos += 4;
 		}
 	} else {
+		early[0] = amdgpu_ring_get_rptr(ring) & ring->buf_mask;
+		early[1] = amdgpu_ring_get_wptr(ring) & ring->buf_mask;
+
 		p = early[0];
 		if (early[0] <= early[1])
-			size = (early[1] - early[0]);
+			avail_dw = early[1] - early[0];
 		else
-			size = ring->ring_size - (early[0] - early[1]);
+			avail_dw = ring->buf_mask + 1 - (early[0] - early[1]);
 
-		while (size) {
+		start_dw = (*pos > 12) ? ((*pos - 12) >> 2) : 0;
+		if (start_dw >= avail_dw)
+			goto out;
+
+		p = (p + start_dw) & ring->ptr_mask;
+		avail_dw -= start_dw;
+		read_dw = min_t(u32, avail_dw, size >> 2);
+
+		while (read_dw) {
 			if (p == early[1])
 				goto out;
 
@@ -639,9 +651,10 @@ static ssize_t amdgpu_debugfs_ring_read(struct file *f, char __user *buf,
 
 			buf += 4;
 			result += 4;
-			size--;
+			read_dw--;
 			p++;
 			p &= ring->ptr_mask;
+			*pos += 4;
 		}
 	}
 
-- 
2.53.0