[PATCH] drm/gpusvm: Zero HMM PFNs before scanning ranges

[PATCH] drm/gpusvm: Zero HMM PFNs before scanning ranges

[Stanislav Kinsburskii]

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,
 	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;
 

✗ LGCI.VerificationFailed: failure for drm/gpusvm: Zero HMM PFNs before scanning ranges

[Patchwork]

== Series Details ==

Series: drm/gpusvm: Zero HMM PFNs before scanning ranges
URL   : https://patchwork.freedesktop.org/series/170665/
State : failure

== Summary ==

Series author address 'skinsburskii@gmail.com' is not on the allowlist, which prevents CI from being automatically triggered.
If you want CI to run for this series, ask Patchwork project owners to click 'retest' on the series in Patchwork.
Exception occurred during validation, bailing out!
Build URL: http://intel-gfx-ci-public.igk.intel.com:8080/job/xe_pw_trigger/1218275/ (on master)

Re: [PATCH] drm/gpusvm: Zero HMM PFNs before scanning ranges

[Matthew Brost]

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;
>  
> 
> 

Re: [PATCH] drm/gpusvm: Zero HMM PFNs before scanning ranges

[Stanislav Kinsburskii]

On Mon, Jul 20, 2026 at 11:54:50AM -0700, Matthew Brost wrote:
> 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
> 

No, these two are fine, as the faulting is done with HMM_PFN_REQ_FAULT,
which either populates all the PFNs or fails.

The only case where PFNs must be zeroed is when the caller wants to
collect the mapped PFNs. In this case, the missing PFNs are simply
ignored by the HMM framework.

Thanks,
Stanislav

> 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;
> >  
> > 
> > 

Re: [PATCH] drm/gpusvm: Zero HMM PFNs before scanning ranges

[Matthew Brost]

On Mon, Jul 20, 2026 at 04:48:02PM -0700, Stanislav Kinsburskii wrote:
> On Mon, Jul 20, 2026 at 11:54:50AM -0700, Matthew Brost wrote:
> > 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
> > 
> 
> No, these two are fine, as the faulting is done with HMM_PFN_REQ_FAULT,
> which either populates all the PFNs or fails.
> 

Ah, yes clearly misunderstood the issue here / didn't read the commit
message.

This patch LGTM:
Reviewed-by: Matthew Brost <matthew.brost@intel.com>

Will merge to drm-misc-fixes shortly.

But then drm_gpusvm_check_pages() should be fixed too as we don't set
HMM_PFN_REQ_FAULT there either.

Matt

> The only case where PFNs must be zeroed is when the caller wants to
> collect the mapped PFNs. In this case, the missing PFNs are simply
> ignored by the HMM framework.
> 
> Thanks,
> Stanislav
> 
> > 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;
> > >  
> > > 
> > > 

Re: [PATCH] drm/gpusvm: Zero HMM PFNs before scanning ranges

[Stanislav Kinsburskii]

On Mon, Jul 20, 2026 at 05:26:52PM -0700, Matthew Brost wrote:
> On Mon, Jul 20, 2026 at 04:48:02PM -0700, Stanislav Kinsburskii wrote:
> > On Mon, Jul 20, 2026 at 11:54:50AM -0700, Matthew Brost wrote:
> > > 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
> > > 
> > 
> > No, these two are fine, as the faulting is done with HMM_PFN_REQ_FAULT,
> > which either populates all the PFNs or fails.
> > 
> 
> Ah, yes clearly misunderstood the issue here / didn't read the commit
> message.
> 
> This patch LGTM:
> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> 
> Will merge to drm-misc-fixes shortly.
> 
> But then drm_gpusvm_check_pages() should be fixed too as we don't set
> HMM_PFN_REQ_FAULT there either.
> 

Indeed.
Please, see v2 of the patch.

Thanks,
Stanislav

> Matt
> 
> > The only case where PFNs must be zeroed is when the caller wants to
> > collect the mapped PFNs. In this case, the missing PFNs are simply
> > ignored by the HMM framework.
> > 
> > Thanks,
> > Stanislav
> > 
> > > 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;
> > > >  
> > > > 
> > > >