[PATCH AUTOSEL 6.19] drm/amdgpu: mark invalid records with U64_MAX

[Sasha Levin <sashal@kernel.org>]

From: Gangliang Xie <ganglxie@amd.com>

[ Upstream commit 0028b86b52f7609e36af635ef6cb908925306233 ]

set retired_page of invalid ras records to U64_MAX, and skip
them when reading ras records

Signed-off-by: Gangliang Xie <ganglxie@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@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:

## Analysis of commit: "drm/amdgpu: mark invalid records with U64_MAX"

### Commit Message Analysis

The commit message is terse: "set retired_page of invalid ras records to
U64_MAX, and skip them when reading ras records." This describes a fix
for handling invalid RAS (Reliability, Availability, Serviceability) bad
page records in AMD GPU drivers.

### Code Change Analysis

Let me examine the two changes in detail:

**Change 1: `__amdgpu_ras_restore_bad_pages`** (the write path)

When restoring bad pages from EEPROM, if
`amdgpu_ras_check_bad_page_unlock()` returns true (meaning the page is
already tracked / is a duplicate), the old code would increment
`data->count` and decrement `data->space_left` but **leave the
`data->bps[data->count]` entry uninitialized** (or containing whatever
stale data was there). The new code sets
`data->bps[data->count].retired_page = U64_MAX` to explicitly mark this
slot as invalid before incrementing the count.

This is a bug fix: previously, when a duplicate bad page was detected
during restore, a slot was consumed in the `data->bps` array without
being properly initialized. This uninitialized entry could contain
garbage data — a stale or random `retired_page` value.

**Change 2: `amdgpu_ras_badpages_read`** (the read path)

When reading bad pages, the new code skips entries where `retired_page
== U64_MAX`. This ensures that the invalid/placeholder entries created
in Change 1 are not reported to userspace or used downstream.

### Bug Mechanism

The bug is:
1. During `__amdgpu_ras_restore_bad_pages`, duplicate bad pages cause a
   slot to be consumed in the `bps` array with uninitialized content
2. When `amdgpu_ras_badpages_read` later iterates over entries, it would
   read these uninitialized entries, potentially reporting garbage
   retired page addresses
3. This could lead to incorrect bad page tracking — the RAS subsystem
   might try to retire pages at wrong addresses, potentially causing
   data corruption or incorrect memory management on the GPU

### Classification

This is a **bug fix** — it fixes uninitialized data in the RAS bad page
tracking array. The RAS subsystem is responsible for tracking pages with
uncorrectable memory errors on the GPU. Incorrect tracking could lead
to:
- Reporting wrong bad pages to userspace
- Failing to properly isolate bad memory regions
- Potential data corruption if bad pages are not properly retired

### Scope and Risk Assessment

- **Files changed**: 1 file (`amdgpu_ras.c`)
- **Lines changed**: ~6 lines of new code (2 comment lines + 4 code
  lines)
- **Risk**: Very low — the changes are additive (adding a sentinel value
  and a skip check), don't change control flow for valid entries, and
  are confined to RAS error handling
- **Subsystem**: AMD GPU RAS — important for data center and workstation
  users with AMD GPUs that have ECC memory

### Dependency Check

The change uses `U64_MAX` which is a standard kernel constant. The
functions modified (`amdgpu_ras_badpages_read` and
`__amdgpu_ras_restore_bad_pages`) are well-established in the amdgpu
driver. No dependency on other recent commits is apparent.

### User Impact

Users with AMD GPUs (especially data center GPUs like MI-series with ECC
memory) rely on the RAS subsystem to correctly track and retire bad
memory pages. If bad page records contain garbage data:
- The GPU driver may attempt to retire incorrect pages
- Bad pages may not actually be retired, leading to repeated
  uncorrectable errors
- System reliability for GPU compute workloads could be affected

### Stability Indicators

- **Reviewed-by: Tao Zhou** — subsystem reviewer has approved
- **Signed-off-by: Alex Deucher** — AMD GPU maintainer has signed off
- The fix is straightforward and the sentinel value approach is a well-
  understood pattern

### Concerns

- The commit is small and surgical
- The sentinel value `U64_MAX` is a valid choice since no real page
  address would be `U64_MAX`
- The fix addresses both the write path (marking invalid) and read path
  (skipping invalid), so it's self-contained

### Verdict

This fixes a real bug: uninitialized data in the RAS bad page array that
could lead to incorrect bad page reporting and handling. The fix is
small (6 lines), self-contained, well-reviewed, and low-risk. It meets
stable kernel criteria: it's obviously correct, fixes a real bug
affecting data integrity in GPU RAS handling, and is small in scope.

**YES**

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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 3d51a3c8852ad..a2a0a7b994d16 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -2777,6 +2777,10 @@ static int amdgpu_ras_badpages_read(struct amdgpu_device *adev,
 			if (!data->bps[i].ts)
 				continue;
 
+			/* U64_MAX is used to mark the record as invalid */
+			if (data->bps[i].retired_page == U64_MAX)
+				continue;
+
 			bps[r].bp = data->bps[i].retired_page;
 			r++;
 			if (r >= count)
@@ -3083,6 +3087,8 @@ static int __amdgpu_ras_restore_bad_pages(struct amdgpu_device *adev,
 
 		if (amdgpu_ras_check_bad_page_unlock(con,
 			bps[j].retired_page << AMDGPU_GPU_PAGE_SHIFT)) {
+			/* set to U64_MAX to mark it as invalid */
+			data->bps[data->count].retired_page = U64_MAX;
 			data->count++;
 			data->space_left--;
 			continue;
-- 
2.51.0