From: sashiko-bot@kernel.org
To: "Yitao Jiang" <jytscientist@hotmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm/amdgpu: block THP for HSA userptr notifiers
Date: Thu, 25 Jun 2026 11:26:19 +0000 [thread overview]
Message-ID: <20260625112620.3DA321F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <SY1PR01MB1059636EEFF3E5C5156F899B8C0EC2@SY1PR01MB10596.ausprd01.prod.outlook.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Unaligned user_addr from KFD_IOC_ALLOC_MEMORY_OF_GPU causes VMA tree corruption via split_vma()
--
commit 84a588c64a29eedb721607110e005505178f21fc
Author: Yitao Jiang <jytscientist@hotmail.com>
drm/amdgpu: block THP for HSA userptr notifiers
This commit modifies the registration of HSA userptr interval notifiers
to use the MMU_INTERVAL_NOTIFIER_BLOCK_THP flag. This prevents CPU THP
remaps of active userptr ranges from causing asynchronous GPU work failures.
GFX userptrs continue to use the existing notifier path.
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c
> index 99bc9ad67d5b8..c0b36164c35e2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c
[ ... ]
> @@ -130,16 +131,24 @@ static const struct mmu_interval_notifier_ops amdgpu_hmm_hsa_ops = {
> */
> int amdgpu_hmm_register(struct amdgpu_bo *bo, unsigned long addr)
> {
[ ... ]
> + if (bo->kfd_bo) {
> + mmap_write_lock(mm);
> + r = mmu_interval_notifier_insert_locked_flags(&bo->notifier, mm,
> + addr, size,
> + &amdgpu_hmm_hsa_ops,
> + MMU_INTERVAL_NOTIFIER_BLOCK_THP);
[Severity: Critical]
Can addr be unaligned when passed to this function?
A user space process can call the KFD_IOC_ALLOC_MEMORY_OF_GPU ioctl with the
KFD_IOC_ALLOC_MEM_FLAGS_USERPTR flag and provide an unaligned virtual address
in args->mmap_offset. The ioctl handler in kfd_ioctl_alloc_memory_of_gpu()
(in drivers/gpu/drm/amd/amdkfd/kfd_chardev.c) does not enforce page alignment
on this offset:
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c:kfd_ioctl_alloc_memory_of_gpu() {
...
err = amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
dev->adev, args->va_addr, args->size,
pdd->drm_priv, (struct kgd_mem **) &mem, &offset,
flags, false);
...
}
The unaligned offset propagates through init_user_pages() unmodified as
user_addr, which is eventually passed here as addr to amdgpu_hmm_register().
With the MMU_INTERVAL_NOTIFIER_BLOCK_THP flag added by this patch, the core
MM calls mmu_interval_notifier_block_thp_locked(), which uses this addr as
the start address. It iteratively passes this address to vma_modify_flags()
and subsequently split_vma().
Since VMA boundaries must be strictly page-aligned, split_vma() will corrupt
the VMA tree and break invariants by applying the unaligned address to the new
VMA bounds. This can lead to kernel panics or a local denial-of-service.
Should addr and size be aligned before calling
mmu_interval_notifier_insert_locked_flags(), or should the ioctl enforce
page alignment on user pointers?
--
Sashiko AI review · https://sashiko.dev/#/patchset/SY1PR01MB10596EB75463208A8E1EBBA0FC0EC2@SY1PR01MB10596.ausprd01.prod.outlook.com?part=2
next prev parent reply other threads:[~2026-06-25 11:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 10:59 [PATCH 0/3] mm/mmu_notifier, drm/amdgpu: block THP for GPU user mappings Yitao Jiang
2026-06-25 10:59 ` [PATCH 1/3] mm/mmu_notifier: let interval notifiers block THP Yitao Jiang
2026-06-25 11:18 ` sashiko-bot
2026-06-25 11:50 ` David Hildenbrand (Arm)
2026-06-25 11:58 ` Lorenzo Stoakes
2026-06-25 10:59 ` [PATCH 2/3] drm/amdgpu: block THP for HSA userptr notifiers Yitao Jiang
2026-06-25 11:26 ` sashiko-bot [this message]
2026-06-25 12:36 ` Christian König
2026-06-25 10:59 ` [PATCH 3/3] drm/amdkfd: block THP for non-replayable SVM ranges Yitao Jiang
2026-06-25 11:11 ` sashiko-bot
2026-06-25 11:47 ` [PATCH 0/3] mm/mmu_notifier, drm/amdgpu: block THP for GPU user mappings David Hildenbrand (Arm)
2026-06-25 11:54 ` Lorenzo Stoakes
2026-06-25 12:14 ` 回复: " 蒋 亦韬
2026-06-25 12:35 ` Christian König
2026-06-25 13:01 ` 回复: " 蒋 亦韬
2026-06-25 13:06 ` Christian König
2026-06-25 20:51 ` Kuehling, Felix
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=20260625112620.3DA321F00A3E@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jytscientist@hotmail.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.