[PATCH] drm/gpuvm: Do not prepare NULL objects

[PATCH] drm/gpuvm: Do not prepare NULL objects

[Jonathan Cavitt]

Statis analysis issue:

drm_gpuvm_prepare_range issues an exec_object_prepare call to all
drm_gem_objects mapped between addr and addr + range.  However, it is
possible (albeit very unlikely) that the objects found through
drm_gpuvm_for_each_va_range (as connected to va->gem) are NULL, as seen
in other functions such as drm_gpuva_link and drm_gpuva_unlink_defer.

Do not prepare NULL objects.

Fixes: 50c1a36f594b ("drm/gpuvm: track/lock/validate external/evicted objects")
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
 drivers/gpu/drm/drm_gpuvm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index 14469765a780..76f70686f0e6 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -1322,6 +1322,9 @@ drm_gpuvm_prepare_range(struct drm_gpuvm *gpuvm, struct drm_exec *exec,
 	drm_gpuvm_for_each_va_range(va, gpuvm, addr, end) {
 		struct drm_gem_object *obj = va->gem.obj;
 
+		if (unlikely(!obj))
+			continue;
+
 		ret = exec_prepare_obj(exec, obj, num_fences);
 		if (ret)
 			return ret;
-- 
2.43.0

Re: [PATCH] drm/gpuvm: Do not prepare NULL objects

[Krzysztof Karas]

Hi Jonathan,

On 2026-01-30 at 19:19:54 +0000, Jonathan Cavitt wrote:
> Statis analysis issue:
> 
> drm_gpuvm_prepare_range issues an exec_object_prepare call to all
> drm_gem_objects mapped between addr and addr + range.  However, it is
> possible (albeit very unlikely) that the objects found through
> drm_gpuvm_for_each_va_range (as connected to va->gem) are NULL, as seen
> in other functions such as drm_gpuva_link and drm_gpuva_unlink_defer.
> 
> Do not prepare NULL objects.
> 
> Fixes: 50c1a36f594b ("drm/gpuvm: track/lock/validate external/evicted objects")
> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
>  drivers/gpu/drm/drm_gpuvm.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
> index 14469765a780..76f70686f0e6 100644
> --- a/drivers/gpu/drm/drm_gpuvm.c
> +++ b/drivers/gpu/drm/drm_gpuvm.c
> @@ -1322,6 +1322,9 @@ drm_gpuvm_prepare_range(struct drm_gpuvm *gpuvm, struct drm_exec *exec,
>  	drm_gpuvm_for_each_va_range(va, gpuvm, addr, end) {
>  		struct drm_gem_object *obj = va->gem.obj;
>  
> +		if (unlikely(!obj))
> +			continue;
> +
>  		ret = exec_prepare_obj(exec, obj, num_fences);
>  		if (ret)
>  			return ret;
> -- 
> 2.43.0
> 
Since there alerady such checks in other functions, as you
pointed out above and the change looks sane:

Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com>

-- 
Best Regards,
Krzysztof

Re: [PATCH] drm/gpuvm: Do not prepare NULL objects

[Danilo Krummrich]

(Cc: Alice)

On Fri Jan 30, 2026 at 8:19 PM CET, Jonathan Cavitt wrote:
> Statis analysis issue:
>
> drm_gpuvm_prepare_range issues an exec_object_prepare call to all
> drm_gem_objects mapped between addr and addr + range.  However, it is
> possible (albeit very unlikely) that the objects found through

It is not as unlikely as you might think. The documentation of
drm_gpuvm_for_each_va_range() explicitly states:

	"This iterator does not skip over the &drm_gpuvm's @kernel_alloc_node."

And the kernel_alloc_node does not have a GEM object set. Also, drivers are free
to insert VAs that do not have a GEM object set, e.g. when they have the
DRM_GPUVA_SPARSE flag set.

> drm_gpuvm_for_each_va_range (as connected to va->gem) are NULL, as seen
> in other functions such as drm_gpuva_link and drm_gpuva_unlink_defer.

That said, there is a "real" justification, other than "we do the same thing in
other functions" that would have been good to put this into the commit message.

The reason I say "would have been" is because this patch has already been
applied -- unfortunately without going through the corresponding maintainer (and
non-Intel reviewers). I only noticed it by accident as I saw it pop up in
drm-misc-next.

No action needed as the code itself is obviously correct, but for the next time,
please make sure to send patches to the corresponding maintainers and reviewers.

- Danilo

RE: [PATCH] drm/gpuvm: Do not prepare NULL objects

[Cavitt, Jonathan]

-----Original Message-----
From: Danilo Krummrich <dakr@kernel.org> 
Sent: Thursday, April 16, 2026 1:01 PM
To: Cavitt, Jonathan <jonathan.cavitt@intel.com>
Cc: dri-devel@lists.freedesktop.org; Gupta, Saurabhg <saurabhg.gupta@intel.com>; Zuo, Alex <alex.zuo@intel.com>; Brost, Matthew <matthew.brost@intel.com>; thomas.hellstrom@linux.intel.com; aliceryhl@google.com; dri-devel <dri-devel-bounces@lists.freedesktop.org>
Subject: Re: [PATCH] drm/gpuvm: Do not prepare NULL objects
> 
> (Cc: Alice)
> 
> On Fri Jan 30, 2026 at 8:19 PM CET, Jonathan Cavitt wrote:
> > Statis analysis issue:
> >
> > drm_gpuvm_prepare_range issues an exec_object_prepare call to all
> > drm_gem_objects mapped between addr and addr + range.  However, it is
> > possible (albeit very unlikely) that the objects found through
> 
> It is not as unlikely as you might think. The documentation of
> drm_gpuvm_for_each_va_range() explicitly states:
> 
> 	"This iterator does not skip over the &drm_gpuvm's @kernel_alloc_node."
> 
> And the kernel_alloc_node does not have a GEM object set. Also, drivers are free
> to insert VAs that do not have a GEM object set, e.g. when they have the
> DRM_GPUVA_SPARSE flag set.
> 
> > drm_gpuvm_for_each_va_range (as connected to va->gem) are NULL, as seen
> > in other functions such as drm_gpuva_link and drm_gpuva_unlink_defer.
> 
> That said, there is a "real" justification, other than "we do the same thing in
> other functions" that would have been good to put this into the commit message.
> 
> The reason I say "would have been" is because this patch has already been
> applied -- unfortunately without going through the corresponding maintainer (and
> non-Intel reviewers). I only noticed it by accident as I saw it pop up in
> drm-misc-next.
> 
> No action needed as the code itself is obviously correct, but for the next time,
> please make sure to send patches to the corresponding maintainers and reviewers.

Question for the future:
Is Lankhorst, Maarten a proper maintainer for this component?
If not, is there a list I can reference to determine who the proper maintainers I should
be contacting are?
-Jonathan Cavitt

> 
> - Danilo
> 

Re: [PATCH] drm/gpuvm: Do not prepare NULL objects

[Danilo Krummrich]

On Thu Apr 16, 2026 at 10:23 PM CEST, Jonathan Cavitt wrote:
> Question for the future:
> Is Lankhorst, Maarten a proper maintainer for this component? 

Maarten is one of the drm-misc tree maintainers.

DRM is a bit special in this regard compared to other kernel subsystems, as DRM
also allows non-maintainers to push to development trees. Yet, those development
trees still need to be run by someone and those people are the tree maintainers.

Additionally, there are people maintaining the individual components, drivers,
etc. and those are usually the people with the strongest domain knowledge.

Patches should be sent to both the tree maintainers and the component
maintainers.

> If not, is there a list I can reference to determine who the proper
> maintainers I should be contacting are?

Absolutely, everything is documented in the MAINTAINERS file in the kernel tree.

The best way to figure out who to send patches to is to use
./scripts/get_maintainer.pl. The script should provide you with the full list of
all relevant maintainers and reviewers for your patch.

Additionally, it also outputs people who have been involved in the corresponding
component and may be worth Cc'ing as well.

If you run it for your patch you should get the output below.

I hope this helps!

- Danilo

--

	$ ./scripts/get_maintainer.pl ./20260130_jonathan_cavitt_drm_gpuvm_do_not_prepare_null_objects.mbx
	Danilo Krummrich <dakr@kernel.org> (maintainer:DRM GPUVM,blamed_fixes:1/1=100%)
	Matthew Brost <matthew.brost@intel.com> (reviewer:DRM GPUVM)
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com> (reviewer:DRM GPUVM,blamed_fixes:1/1=100%)
	Alice Ryhl <aliceryhl@google.com> (reviewer:DRM GPUVM)
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (maintainer:DRM DRIVERS AND MISC GPU PATCHES)
	Maxime Ripard <mripard@kernel.org> (maintainer:DRM DRIVERS AND MISC GPU PATCHES)
	Thomas Zimmermann <tzimmermann@suse.de> (maintainer:DRM DRIVERS AND MISC GPU PATCHES)
	David Airlie <airlied@gmail.com> (maintainer:DRM DRIVERS)
	Simona Vetter <simona@ffwll.ch> (maintainer:DRM DRIVERS)
	"Christian König" <christian.koenig@amd.com> (blamed_fixes:1/1=100%)
	Boris Brezillon <boris.brezillon@collabora.com> (blamed_fixes:1/1=100%)
	dri-devel@lists.freedesktop.org (open list:DRM GPUVM)
	linux-kernel@vger.kernel.org (open list)
	DRM GPUVM status: Supported

Re: [PATCH] drm/gpuvm: Do not prepare NULL objects

[Luben Tuikov]

[-- Attachment #1.1.1: Type: text/plain, Size: 1523 bytes --]

On 2026-04-16 16:44, Danilo Krummrich wrote:
> On Thu Apr 16, 2026 at 10:23 PM CEST, Jonathan Cavitt wrote:
>> Question for the future:
>> Is Lankhorst, Maarten a proper maintainer for this component? 
> 
> Maarten is one of the drm-misc tree maintainers.
> 
> DRM is a bit special in this regard compared to other kernel subsystems, as DRM
> also allows non-maintainers to push to development trees. Yet, those development
> trees still need to be run by someone and those people are the tree maintainers.
> 
> Additionally, there are people maintaining the individual components, drivers,
> etc. and those are usually the people with the strongest domain knowledge.
> 
> Patches should be sent to both the tree maintainers and the component
> maintainers.
> 
>> If not, is there a list I can reference to determine who the proper
>> maintainers I should be contacting are?
> 
> Absolutely, everything is documented in the MAINTAINERS file in the kernel tree.
> 
> The best way to figure out who to send patches to is to use
> ./scripts/get_maintainer.pl. The script should provide you with the full list of
> all relevant maintainers and reviewers for your patch.
> 
> Additionally, it also outputs people who have been involved in the corresponding
> component and may be worth Cc'ing as well.
> 
> If you run it for your patch you should get the output below.
> 
> I hope this helps!

That's a great response! Indeed, the get_maintainer.pl is a good tool to use.

-- 
Regards,
Luben

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 677 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]