All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Lizhi Hou" <lizhi.hou@amd.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH V2] accel/amdxdna: Set HMM_PFN_REQ_WRITE for writable BO faults
Date: Thu, 17 Sep 2026 17:08:18 +0000	[thread overview]
Message-ID: <20260917170818.E3CC41F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260917165406.1881899-1-lizhi.hou@amd.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] accel/amdxdna: data race on default_flags and illegal vma_lookup in invalidation
--

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

accel/amdxdna: Set HMM_PFN_REQ_WRITE for writable BO faults

This commit ensures HMM_PFN_REQ_WRITE is set when handling faults for VMAs
with VM_WRITE. It introduces amdxdna_umap_set_fault_flags() to check VMA
permissions and apply the flag, calling it from the notifier registration and
invalidation paths.

> diff --git a/drivers/accel/amdxdna/amdxdna_gem.c b/drivers/accel/amdxdna/amdxdna_gem.c
> index 5a1a2ee261b76..4f6fe982583fd 100644
> --- a/drivers/accel/amdxdna/amdxdna_gem.c
> +++ b/drivers/accel/amdxdna/amdxdna_gem.c
[ ... ]
> @@ -249,6 +249,20 @@ u64 amdxdna_gem_dev_addr(struct amdxdna_gem_obj *abo)
>  	return amdxdna_obj_dma_addr(abo);
>  }
>  
> +static void amdxdna_umap_set_fault_flags(struct amdxdna_umap *mapp,
> +					 struct vm_area_struct *vma)
> +{
> +	mapp->range.default_flags = HMM_PFN_REQ_FAULT;

[Severity: High]
Does this code introduce a data race? amdxdna_hmm_invalidate is an MMU
interval notifier invalidation callback, which can run concurrently with the
driver's page fault handler (hmm_range_fault_unlocked_timeout). Modifying
mapp->range.default_flags here without synchronization can race with
hmm_range_fault, which reads range->default_flags locklessly.

> +
> +	if (!vma)
> +		vma = vma_lookup(mapp->notifier.mm, mapp->range.start);

[Severity: High]
Can calling vma_lookup here trigger a lockdep warning or use-after-free?
When called from amdxdna_hmm_invalidate, MMU notifiers (such as those
triggered by page reclaim or migration) do not guarantee that mmap_lock is
held, and this code does not take rcu_read_lock(). Calling vma_lookup
without either lock is unsafe, and may cause a use-after-free when
dereferencing vma->vm_flags on a potentially freed VMA.

> +
> +	if (vma && vma->vm_start <= mapp->range.start &&
> +	    vma->vm_end >= mapp->range.end &&
> +	    (vma->vm_flags & VM_WRITE))
> +		mapp->range.default_flags |= HMM_PFN_REQ_WRITE;
> +}
> +
>  static bool amdxdna_hmm_invalidate(struct mmu_interval_notifier *mni,
>  				   const struct mmu_notifier_range *range,
>  				   unsigned long cur_seq)
> @@ -270,6 +284,7 @@ static bool amdxdna_hmm_invalidate(struct mmu_interval_notifier *mni,
>  	down_write(&xdna->notifier_lock);
>  	abo->mem.map_invalid = true;
>  	mapp->invalid = true;
> +	amdxdna_umap_set_fault_flags(mapp, NULL);
>  	mmu_interval_set_seq(&mapp->notifier, cur_seq);
>  	up_write(&xdna->notifier_lock);

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

      reply	other threads:[~2026-09-17 17:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-17 16:54 [PATCH V2] accel/amdxdna: Set HMM_PFN_REQ_WRITE for writable BO faults Lizhi Hou
2026-09-17 17:08 ` sashiko-bot [this message]

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=20260917170818.E3CC41F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=lizhi.hou@amd.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.