All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Junrui Luo" <moonafterrain@outlook.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/amdgpu: add the BO-va mapping offset when kmapping an IB
Date: Thu, 06 Aug 2026 05:06:28 +0000	[thread overview]
Message-ID: <20260806050628.EB0B11F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260806-amdgpu-fixes-v1-3-ce247012d4da@outlook.com>

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

Pre-existing issues:
- [High] Incomplete bug fix: multiple CPU-side consumers of `amdgpu_cs_find_mapping()` ignore `mapping->offset`, causing validation bypasses and incorrect hardware programming.
--

--- Patch [3]: [PATCH 3/3] drm/amdgpu: add the BO-va mapping offset when kmapping an IB ---
commit d8bdec727584870cf6250f253ea262e5bbf96aef
Author: Junrui Luo <moonafterrain@outlook.com>

drm/amdgpu: add the BO-va mapping offset when kmapping an IB

This patch fixes the CPU-side view of indirect buffers (IBs) in
amdgpu_cs_patch_ibs(). It adds the missing mapping offset to the kmapped
pointer so it accurately reflects the bytes programmed into the page tables.

> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index 9c514cb010966..a72cee871af3d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -1047,7 +1047,7 @@ static int amdgpu_cs_patch_ibs(struct amdgpu_cs_parser *p,
>  		if (r)
>  			return r;
>  
> -		kptr += va_start - (m->start * AMDGPU_GPU_PAGE_SIZE);
> +		kptr += m->offset + va_start - (m->start * AMDGPU_GPU_PAGE_SIZE);

[Severity: High]
This is a pre-existing issue, but while this patch fixes the mapping offset
calculation here, do we need to apply the same fix to other CPU-side consumers
of amdgpu_cs_find_mapping()?

The commit message notes that every other CPU-side consumer omits
mapping->offset in the same way. Does this mean they are still vulnerable to
incorrect hardware programming or validation bypasses?

For example, when calculating the physical GPU address to patch into the UVD
IB, amdgpu_uvd_cs_pass2() in drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c does not
include mapping->offset:

	addr -= mapping->start * AMDGPU_GPU_PAGE_SIZE;
	start += addr;

Similar calculations omitting mapping->offset occur in:
- drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:amdgpu_vce_cs_reloc()
- drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c:vcn_v3_0_dec_msg()
- drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c:vcn_v4_0_dec_msg()
- drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c:amdgpu_dev_coredump_print_ibs()
- drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c:amdgpu_userq_fence_read_wptr()

If a user submits a command stream with an IB mapped with a non-zero
offset_in_bo, could this lead to hardware hangs by bypassing VCN codec
validation, or corrupt UVD/VCE command stream physical address patching?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806-amdgpu-fixes-v1-0-ce247012d4da@outlook.com?part=3

  reply	other threads:[~2026-08-06  5:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-06  4:45 [PATCH 0/3] drm/amdgpu: three independent fixes in the CS and VM paths Junrui Luo via B4 Relay
2026-08-06  4:45 ` Junrui Luo
2026-08-06  4:45 ` [PATCH 1/3] drm/amdgpu: disallow multiple FENCE chunks in one submit Junrui Luo via B4 Relay
2026-08-06  4:45   ` Junrui Luo
2026-08-06 11:54   ` Christian König
2026-08-06 20:25     ` Alex Deucher
2026-08-06  4:45 ` [PATCH 2/3] drm/amdgpu: fix VM update overrun on non-4K page kernels Junrui Luo via B4 Relay
2026-08-06  4:45   ` Junrui Luo
2026-08-06  5:00   ` sashiko-bot
2026-08-06 11:59   ` Christian König
2026-08-08 17:03     ` Junrui Luo
2026-08-10 13:07       ` Christian König
2026-08-06  4:45 ` [PATCH 3/3] drm/amdgpu: add the BO-va mapping offset when kmapping an IB Junrui Luo via B4 Relay
2026-08-06  4:45   ` Junrui Luo
2026-08-06  5:06   ` sashiko-bot [this message]
2026-08-06 12:05   ` Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260806050628.EB0B11F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=moonafterrain@outlook.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.