Re: [PATCH V1] accel/amdxdna: Set HMM_PFN_REQ_WRITE for writable BO faults

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] amdxdna: stale VMA permissions cache in hmm_range_fault breaks mprotect()
--

commit bfad63cfebe7db959de532304657044547acec26
Author: Lizhi Hou <lizhi.hou@amd.com>

accel/amdxdna: Set HMM_PFN_REQ_WRITE for writable BO faults

This patch updates aie2_populate_range() to check the VMA flags and
set HMM_PFN_REQ_WRITE when the VMA has VM_WRITE. This ensures that
handle_mm_fault() requests write permissions instead of populating CPU
page tables with read-only PTEs.

> diff --git a/drivers/accel/amdxdna/amdxdna_gem.c b/drivers/accel/amdxdna/amdxdna_gem.c
> index 5a1a2ee261b76..df8e76b5f38a0 100644
> --- a/drivers/accel/amdxdna/amdxdna_gem.c
> +++ b/drivers/accel/amdxdna/amdxdna_gem.c
> @@ -429,6 +429,8 @@ static int amdxdna_hmm_register(struct amdxdna_gem_obj *abo,
>  	mapp->range.start = vma->vm_start;
>  	mapp->range.end = vma->vm_end;
>  	mapp->range.default_flags = HMM_PFN_REQ_FAULT;
> +	if (vma->vm_flags & VM_WRITE)
> +		mapp->range.default_flags |= HMM_PFN_REQ_WRITE;

[Severity: High]
Does this statically cache the VMA write permissions during mmap?

If userspace later downgrades permissions via mprotect(PROT_READ) and
submits a job, could hmm_range_fault() fail with -EPERM because it still
demands write access on a read-only VMA? Conversely, if userspace upgrades
to PROT_WRITE via mprotect, it seems the driver would fail to request write
permissions, which might re-introduce the IOMMU faults this patch intended
to fix.

Since the permissions are permanently cached into the HMM range default
flags in amdxdna_hmm_register(), any unprivileged userspace application
mapping a buffer object and modifying its permissions could trigger this.

>  	mapp->abo = abo;
>  	kref_init(&mapp->refcnt);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917154920.1872289-1-lizhi.hou@amd.com?part=1