[PATCH 0/3] drm/amdgpu: three independent fixes in the CS and VM paths

[PATCH 0/3] drm/amdgpu: three independent fixes in the CS and VM paths

[Junrui Luo via B4 Relay]

Three independent fixes; no dependency between them, they can be applied
or dropped individually.

Patch 1 rejects submissions carrying more than one AMDGPU_CHUNK_ID_FENCE
chunk.  p->uf_bo is a single-slot field, so every FENCE chunk but the last
leaks a BO reference that outlives handle close and process exit.

Patch 2 clamps the rounded-up entry count in amdgpu_vm_update_range().
Where AMDGPU_GPU_PAGES_IN_CPU_PAGE is greater than 1, a mapping whose GPU
page count is not a multiple of it can round num_entries up past what the
cursor holds and trip BUG_ON(size > cur->remaining) in amdgpu_res_next().
4K-page hosts are unaffected.

Patch 3 adds the mapping offset when computing the CPU-side pointer to an
IB in amdgpu_cs_patch_ibs().  The page tables are programmed from
mapping->offset, so for a mapping created with a non-zero offset_in_bo the
kernel inspects different bytes than the GPU executes.

Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
Junrui Luo (3):
      drm/amdgpu: disallow multiple FENCE chunks in one submit
      drm/amdgpu: fix VM update overrun on non-4K page kernels
      drm/amdgpu: add the BO-va mapping offset when kmapping an IB

 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +++++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +++--
 2 files changed, 8 insertions(+), 3 deletions(-)
---
base-commit: 075b74841bd0065a3bda3440873c747938e69b68
change-id: 20260806-amdgpu-fixes-7ce39504b98d

Best regards,
-- 
Junrui Luo <moonafterrain@outlook.com>

[PATCH 1/3] drm/amdgpu: disallow multiple FENCE chunks in one submit

[Junrui Luo via B4 Relay]

From: Junrui Luo <moonafterrain@outlook.com>

amdgpu_cs_pass1() dispatches on chunk_id once per chunk without
rejecting repeated ids. p->uf_bo is a single-slot field, so a
submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs
amdgpu_cs_p1_user_fence() twice, and the second run overwrites
p->uf_bo with a freshly referenced BO without dropping the reference
taken by the first.

amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE
chunk but the last leaks a BO reference. The leaked BO outlives handle
close and process exit.

Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc
("drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit") did
for p->bo_list.

Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 5445f75741b5..9c514cb01096 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -228,6 +228,10 @@ static int amdgpu_cs_pass1(struct amdgpu_cs_parser *p,
 			if (size < sizeof(struct drm_amdgpu_cs_chunk_fence))
 				goto free_partial_kdata;
 
+			/* Only a single user fence is allowed to simplify handling. */
+			if (p->uf_bo)
+				goto free_partial_kdata;
+
 			ret = amdgpu_cs_p1_user_fence(p, p->chunks[i].kdata,
 						      &uf_offset);
 			if (ret)

-- 
2.51.2

[PATCH 2/3] drm/amdgpu: fix VM update overrun on non-4K page kernels

[Junrui Luo via B4 Relay]

From: Junrui Luo <moonafterrain@outlook.com>

The contiguity scan in amdgpu_vm_update_range() rounds num_entries up to
count * AMDGPU_GPU_PAGES_IN_CPU_PAGE, but count is only constrained by
the loop bound when the loop body executes. The guard
num_entries > AMDGPU_GPU_PAGES_IN_CPU_PAGE proves that
tmp = num_entries / AMDGPU_GPU_PAGES_IN_CPU_PAGE is at least 1, while
the initial count of 2 needs tmp >= 2.

Each iteration consumes a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE, so a
mapping whose GPU page count is not a multiple of it eventually reaches
an iteration where num_entries is above AMDGPU_GPU_PAGES_IN_CPU_PAGE but
below twice that. tmp is then 1, the loop body never runs, count keeps
its initial value, and num_entries is rounded up past what the cursor
holds, tripping BUG_ON(size > cur->remaining) in amdgpu_res_next().
AMDGPU_GEM_VA is DRM_RENDER_ALLOW and amdgpu_vm_verify_parameters() only
requires map_size to be a multiple of AMDGPU_GPU_PAGE_SIZE, so an
unprivileged caller can reach this. On 4K page hosts
AMDGPU_GPU_PAGES_IN_CPU_PAGE is 1, tmp >= 2 always holds, and the bug is
unreachable.

Clamp the rounded-up value against num_entries, mirroring the min() that
amdgpu_res_first() already applies to cur->size. A contiguous short tail
is then mapped in full, and a non-contiguous one falls back to a single
CPU page so the loop still makes forward progress.

Fixes: a39f2a8d7066 ("drm/amdgpu: nuke amdgpu_vm_bo_split_mapping v2")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
Found by code inspection; not tested on hardware. I have no access to a
64K-page host with an AMD GPU, so the BUG_ON() path was not exercised at
runtime.
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index dc6a9d7dd0b2..365a1c4a4527 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1193,8 +1193,9 @@ int amdgpu_vm_update_range(struct amdgpu_device *adev, struct amdgpu_vm *vm,
 				}
 				if (!contiguous)
 					count--;
-				num_entries = count *
-					AMDGPU_GPU_PAGES_IN_CPU_PAGE;
+				num_entries = min(count *
+						  AMDGPU_GPU_PAGES_IN_CPU_PAGE,
+						  num_entries);
 			}
 
 			if (!contiguous) {

-- 
2.51.2

[PATCH 3/3] drm/amdgpu: add the BO-va mapping offset when kmapping an IB

[Junrui Luo via B4 Relay]

From: Junrui Luo <moonafterrain@outlook.com>

amdgpu_cs_patch_ibs() derives the CPU-side view of a UVD/VCE/VCN
indirect buffer from the BO returned by amdgpu_cs_find_mapping():

    r = amdgpu_bo_kmap(aobj, (void **)&kptr);
    kptr += va_start - (m->start * AMDGPU_GPU_PAGE_SIZE);

amdgpu_bo_kmap() returns the start of the BO, so only the displacement
of va_start inside the mapping is added.  The page tables, however, are
programmed from mapping->offset (see amdgpu_vm_bo_update()), which
records the offset_in_bo the client passed to AMDGPU_GEM_VA.  The GPU
therefore resolves va_start to BO byte

    m->offset + (va_start - m->start * AMDGPU_GPU_PAGE_SIZE)

while the kernel inspects the byte m->offset lower.  Whenever an IB is
submitted through a mapping created with a non-zero offset_in_bo, the
two views disagree.

Add the missing term so the kmapped pointer describes the same bytes the
page tables do.

Every other CPU-side consumer of amdgpu_cs_find_mapping() omits
mapping->offset in the same way.

Fixes: 4802ce117786 ("drm/amdgpu: fix UVD/VCE VM emulation")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 9c514cb01096..a72cee871af3 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);
 
 		if (ring->funcs->parse_cs) {
 			memcpy(ib->ptr, kptr, ib->length_dw * 4);

-- 
2.51.2

Re: [PATCH 1/3] drm/amdgpu: disallow multiple FENCE chunks in one submit

[Christian König]

On 8/6/26 06:45, Junrui Luo via B4 Relay wrote:
> amdgpu_cs_pass1() dispatches on chunk_id once per chunk without
> rejecting repeated ids. p->uf_bo is a single-slot field, so a
> submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs
> amdgpu_cs_p1_user_fence() twice, and the second run overwrites
> p->uf_bo with a freshly referenced BO without dropping the reference
> taken by the first.
> 
> amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE
> chunk but the last leaks a BO reference. The leaked BO outlives handle
> close and process exit.
> 
> Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc
> ("drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit") did
> for p->bo_list.
> 
> Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> Assisted-by: Claude:claude-opus-5
> Cc: stable@vger.kernel.org
> Signed-off-by: Junrui Luo <moonafterrain@outlook.com>

Reviewed-by: Christian König <christian.koenig@amd.com>

Thanks,
Christian.

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index 5445f75741b5..9c514cb01096 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -228,6 +228,10 @@ static int amdgpu_cs_pass1(struct amdgpu_cs_parser *p,
>                         if (size < sizeof(struct drm_amdgpu_cs_chunk_fence))
>                                 goto free_partial_kdata;
> 
> +                       /* Only a single user fence is allowed to simplify handling. */
> +                       if (p->uf_bo)
> +                               goto free_partial_kdata;
> +
>                         ret = amdgpu_cs_p1_user_fence(p, p->chunks[i].kdata,
>                                                       &uf_offset);
>                         if (ret)
> 
> --
> 2.51.2
> 
> 

Re: [PATCH 2/3] drm/amdgpu: fix VM update overrun on non-4K page kernels

[Christian König]

On 8/6/26 06:45, Junrui Luo via B4 Relay wrote:
> [Some people who received this message don't often get email from devnull+moonafterrain.outlook.com@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> From: Junrui Luo <moonafterrain@outlook.com>
> 
> The contiguity scan in amdgpu_vm_update_range() rounds num_entries up to
> count * AMDGPU_GPU_PAGES_IN_CPU_PAGE, but count is only constrained by
> the loop bound when the loop body executes. The guard
> num_entries > AMDGPU_GPU_PAGES_IN_CPU_PAGE proves that
> tmp = num_entries / AMDGPU_GPU_PAGES_IN_CPU_PAGE is at least 1, while
> the initial count of 2 needs tmp >= 2.
> 
> Each iteration consumes a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE, so a
> mapping whose GPU page count is not a multiple of it eventually reaches
> an iteration where num_entries is above AMDGPU_GPU_PAGES_IN_CPU_PAGE but
> below twice that. tmp is then 1, the loop body never runs, count keeps
> its initial value, and num_entries is rounded up past what the cursor
> holds, tripping BUG_ON(size > cur->remaining) in amdgpu_res_next().
> AMDGPU_GEM_VA is DRM_RENDER_ALLOW and amdgpu_vm_verify_parameters() only
> requires map_size to be a multiple of AMDGPU_GPU_PAGE_SIZE, so an
> unprivileged caller can reach this. On 4K page hosts
> AMDGPU_GPU_PAGES_IN_CPU_PAGE is 1, tmp >= 2 always holds, and the bug is
> unreachable.
> 
> Clamp the rounded-up value against num_entries, mirroring the min() that
> amdgpu_res_first() already applies to cur->size. A contiguous short tail
> is then mapped in full, and a non-contiguous one falls back to a single
> CPU page so the loop still makes forward progress.
> 
> Fixes: a39f2a8d7066 ("drm/amdgpu: nuke amdgpu_vm_bo_split_mapping v2")
> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> Assisted-by: Claude:claude-opus-5
> Cc: stable@vger.kernel.org
> Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
> ---
> Found by code inspection; not tested on hardware. I have no access to a
> 64K-page host with an AMD GPU, so the BUG_ON() path was not exercised at
> runtime.

That check is clearly not correct. The pages_addr must be fully consumed, otherwise we run into major problems later on.

We could do something like this instead:

if (pages_addr) {
...
	if (WARN_ON(num_entries % AMDGPU_GPU_PAGES_IN_CPU_PAGE))
		return -EINVAL;
...

Regards,
Christian.

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index dc6a9d7dd0b2..365a1c4a4527 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -1193,8 +1193,9 @@ int amdgpu_vm_update_range(struct amdgpu_device *adev, struct amdgpu_vm *vm,
>                                 }
>                                 if (!contiguous)
>                                         count--;
> -                               num_entries = count *
> -                                       AMDGPU_GPU_PAGES_IN_CPU_PAGE;
> +                               num_entries = min(count *
> +                                                 AMDGPU_GPU_PAGES_IN_CPU_PAGE,
> +                                                 num_entries);
>                         }
> 
>                         if (!contiguous) {
> 
> --
> 2.51.2
> 
> 

Re: [PATCH 3/3] drm/amdgpu: add the BO-va mapping offset when kmapping an IB

[Christian König]

On 8/6/26 06:45, Junrui Luo via B4 Relay wrote:
> [Some people who received this message don't often get email from devnull+moonafterrain.outlook.com@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> From: Junrui Luo <moonafterrain@outlook.com>
> 
> amdgpu_cs_patch_ibs() derives the CPU-side view of a UVD/VCE/VCN
> indirect buffer from the BO returned by amdgpu_cs_find_mapping():
> 
>     r = amdgpu_bo_kmap(aobj, (void **)&kptr);
>     kptr += va_start - (m->start * AMDGPU_GPU_PAGE_SIZE);
> 
> amdgpu_bo_kmap() returns the start of the BO, so only the displacement
> of va_start inside the mapping is added.  The page tables, however, are
> programmed from mapping->offset (see amdgpu_vm_bo_update()), which
> records the offset_in_bo the client passed to AMDGPU_GEM_VA.  The GPU
> therefore resolves va_start to BO byte
> 
>     m->offset + (va_start - m->start * AMDGPU_GPU_PAGE_SIZE)
> 
> while the kernel inspects the byte m->offset lower.  Whenever an IB is
> submitted through a mapping created with a non-zero offset_in_bo, the
> two views disagree.
> 
> Add the missing term so the kmapped pointer describes the same bytes the
> page tables do.
> 
> Every other CPU-side consumer of amdgpu_cs_find_mapping() omits
> mapping->offset in the same way.
> 
> Fixes: 4802ce117786 ("drm/amdgpu: fix UVD/VCE VM emulation")

Good catch, but completely irrelevant in practice, so just drop that here.

> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Junrui Luo <moonafterrain@outlook.com>

With that done Reviewed-by: Christian König <christian.koenig@amd.com>

Regards,
Christian.

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index 9c514cb01096..a72cee871af3 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);
> 
>                 if (ring->funcs->parse_cs) {
>                         memcpy(ib->ptr, kptr, ib->length_dw * 4);
> 
> --
> 2.51.2
> 
> 

Re: [PATCH 1/3] drm/amdgpu: disallow multiple FENCE chunks in one submit

[Alex Deucher]

Applied.  Thanks!

On Thu, Aug 6, 2026 at 8:03 AM Christian König <christian.koenig@amd.com> wrote:
>
> On 8/6/26 06:45, Junrui Luo via B4 Relay wrote:
> > amdgpu_cs_pass1() dispatches on chunk_id once per chunk without
> > rejecting repeated ids. p->uf_bo is a single-slot field, so a
> > submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs
> > amdgpu_cs_p1_user_fence() twice, and the second run overwrites
> > p->uf_bo with a freshly referenced BO without dropping the reference
> > taken by the first.
> >
> > amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE
> > chunk but the last leaks a BO reference. The leaked BO outlives handle
> > close and process exit.
> >
> > Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc
> > ("drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit") did
> > for p->bo_list.
> >
> > Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> > Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> > Assisted-by: Claude:claude-opus-5
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
>
> Reviewed-by: Christian König <christian.koenig@amd.com>
>
> Thanks,
> Christian.
>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > index 5445f75741b5..9c514cb01096 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > @@ -228,6 +228,10 @@ static int amdgpu_cs_pass1(struct amdgpu_cs_parser *p,
> >                         if (size < sizeof(struct drm_amdgpu_cs_chunk_fence))
> >                                 goto free_partial_kdata;
> >
> > +                       /* Only a single user fence is allowed to simplify handling. */
> > +                       if (p->uf_bo)
> > +                               goto free_partial_kdata;
> > +
> >                         ret = amdgpu_cs_p1_user_fence(p, p->chunks[i].kdata,
> >                                                       &uf_offset);
> >                         if (ret)
> >
> > --
> > 2.51.2
> >
> >
>

Re: [PATCH 2/3] drm/amdgpu: fix VM update overrun on non-4K page kernels

[Junrui Luo]

On Thu, Aug 06, 2026 at 01:59:52PM +0200, Christian König wrote:
> 
> That check is clearly not correct. The pages_addr must be fully consumed, otherwise we run into major problems later on.

Is that an invariant today?  num_entries <= AMDGPU_GPU_PAGES_IN_CPU_PAGE
skips the scan and is used as it is, so on a 64K page kernel a 4K mapping
maps a single GPU page and pages_addr is not consumed in whole CPU pages
there either.

So what should the code do for a mapping whose size is not a multiple of
AMDGPU_GPU_PAGES_IN_CPU_PAGE?  Could you sketch what you have in mind?

Thanks,
Junrui Luo

Re: [PATCH 2/3] drm/amdgpu: fix VM update overrun on non-4K page kernels

[Christian König]

On 8/8/26 19:03, Junrui Luo wrote:
> On Thu, Aug 06, 2026 at 01:59:52PM +0200, Christian König wrote:
>>
>> That check is clearly not correct. The pages_addr must be fully consumed, otherwise we run into major problems later on.
> 
> Is that an invariant today?  num_entries <= AMDGPU_GPU_PAGES_IN_CPU_PAGE
> skips the scan and is used as it is, so on a 64K page kernel a 4K mapping
> maps a single GPU page and pages_addr is not consumed in whole CPU pages
> there either.

Exactly that doesn't work. On a 64K page kernel mappings *must* be 64K as well.

> So what should the code do for a mapping whose size is not a multiple of
> AMDGPU_GPU_PAGES_IN_CPU_PAGE?  Could you sketch what you have in mind?

That case simply can't happen for user space allocations in the first place.

Regards,
Christian.

> 
> Thanks,
> Junrui Luo