mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: Stanislav Kinsburskii <skinsburskii@gmail.com>
Cc: <maarten.lankhorst@linux.intel.com>, <mripard@kernel.org>,
	<tzimmermann@suse.de>, <airlied@gmail.com>, <simona@ffwll.ch>,
	<thomas.hellstrom@linux.intel.com>,
	<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
	<intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH] drm/gpusvm: Zero HMM PFNs before scanning ranges
Date: Mon, 20 Jul 2026 11:54:50 -0700	[thread overview]
Message-ID: <al5u+iJi1h6FhKsu@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <178406967042.1113483.2116704310277917086.stgit@skinsburskii>

On Tue, Jul 14, 2026 at 03:54:32PM -0700, Stanislav Kinsburskii wrote:
> drm_gpusvm_scan_mm() asks HMM to report the current CPU page-table
> state without faulting missing entries by leaving default_flags set to
> zero. The HMM PFN array is still caller-owned input/output state, and
> the framework may preserve input bits while filling entries. It is not
> safe for the caller to hand HMM an uninitialized array and then treat
> entries without HMM_PFN_VALID as an authoritative unpopulated result.
> 
> Use kvcalloc() for the temporary PFN array so entries that are not
> reported as valid start from the documented zero state. This prevents
> random stack or heap contents from being interpreted as HMM PFN flags or
> PFN values during the scan.
> 
> Fixes: f1d08a586482 ("drm/gpusvm: Introduce a function to scan the current migration state")
> Cc: stable@vger.kernel.org
> Signed-off-by: Stanislav Kinsburskii <skinsburskii@gmail.com>
> ---
>  drivers/gpu/drm/drm_gpusvm.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_gpusvm.c b/drivers/gpu/drm/drm_gpusvm.c
> index 1a8bb83bd28d..c8f489d7ff7e 100644
> --- a/drivers/gpu/drm/drm_gpusvm.c
> +++ b/drivers/gpu/drm/drm_gpusvm.c
> @@ -859,7 +859,7 @@ enum drm_gpusvm_scan_result drm_gpusvm_scan_mm(struct drm_gpusvm_range *range,

Two other cases in gpusvm would need to be fixed as well:

- drm_gpusvm_get_pages
- drm_gpusvm_range_evict

The offending patch is likely the one that added sticky bits to HMM:
`git format-patch -1 285e871884ff3` for above two cases.

While I think zeroing here would be the safest approach, it does not appear
to be a problem in practice because the sticky bits are only used by
`hmm_dma_map_pfn()` and `hmm_dma_unmap_pfn()`.

Also, there are several non-gpusvm cases in the kernel that do not zero
the PFN array either. So I'd say we should either fix the entire kernel
in one pass, document that pfns must initialized to a known state, or
leave this code alone.

Matt

>  	const struct dev_pagemap *other = NULL;
>  	int err, i;
>  
> -	pfns = kvmalloc_array(npages, sizeof(*pfns), GFP_KERNEL);
> +	pfns = kvcalloc(npages, sizeof(*pfns), GFP_KERNEL);
>  	if (!pfns)
>  		return DRM_GPUSVM_SCAN_UNPOPULATED;
>  
> 
> 

  reply	other threads:[~2026-07-20 18:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-14 22:54 Stanislav Kinsburskii
2026-07-20 18:54 ` Matthew Brost [this message]
2026-07-20 23:48   ` Stanislav Kinsburskii
2026-07-21  0:26     ` Matthew Brost
2026-07-21 16:30       ` Stanislav Kinsburskii

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=al5u+iJi1h6FhKsu@gsse-cloud1.jf.intel.com \
    --to=matthew.brost@intel.com \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=skinsburskii@gmail.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tzimmermann@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®