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 <[email protected]>
> Cc: Matthew Brost <[email protected]>
> Cc: Thomas Hellström <[email protected]>
> ---
> 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 <[email protected]>
--
Best Regards,
Krzysztof
