This series fixes two MES queue-init reset paths that still clear ring->wptr_cpu_addr with a plain 32-bit store even though the same carrier is accessed with atomic64_set()/atomic64_read() and support_64bit_ptrs is enabled.
This is not just a missing atomic annotation. The write pointer carrier is used as a shared 64-bit value, so a plain *ring->wptr_cpu_addr = 0 only clears the low 32 bits. A later atomic64_read() can then observe stale high 32 bits instead of a real zeroed reset state. Use atomic64_set((atomic64_t *)ring->wptr_cpu_addr, 0) in both reset paths so the full 64-bit MES wptr is cleared with the same access family as the existing readers and writers. This issue was first flagged by our static analysis tool while scanning for 64-bit atomic write pointer carriers mixed with plain reset stores, then manually audited on Linux v6.18.21. It was further confirmed with a QEMU no-device stand-in that preserved the same access contract: atomic64_set() write, plain low-32 reset, and atomic64_read() readback. In that stand-in, a buggy reset turned 0x12345678abcdeff0 into 0x1234567800000000, while replacing the reset with atomic64_set(..., 0) read back 0x0. Build-tested by compiling mes_v11_0.o and mes_v12_0.o. No AMDGPU hardware was available for end-to-end runtime testing. Runyu Xiao (2): drm/amdgpu/mes11: fix queue init wptr reset drm/amdgpu/mes12: fix queue init wptr reset drivers/gpu/drm/amd/amdgpu/mes_v11_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/mes_v12_0.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.34.1
