Re: [PATCH 1/1] drm/ttm: Avoid NULL pointer deref for evicted BOs

[Matthew Brost <matthew.brost@intel.com>]

On Sun, Oct 12, 2025 at 09:45:32PM +0900, Simon Richter wrote:
> It is possible for a BO to exist that is not currently associated with a
> resource, e.g. because it has been evicted.
> 
> When devcoredump tries to read the contents of all BOs for dumping, we need
> to expect this as well -- in this case, ENODATA is recorded instead of the
> buffer contents.
> 

Please include dri-devel on TTM patches.

> Fixes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6271

s/Fixes/Closes

"Closes" is used for linking to issues, while "Fixes" refers to the
original offending patch that we need to backport to stable. So, you'll
need to include a "Fixes" tag here, along with CC stable.

Let me review this GitLab entry, but it does seem odd that bo->resource
is NULL. What kind of WL is this? I think this might be possible for
a faulting VM that defers validating the BO and performs the bind in the
page fault handler. But for all other WL, I really don’t think this
should be possible—unless I’m missing something.

> ---
>  drivers/gpu/drm/ttm/ttm_bo_vm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index b47020fca199..99bd75be8b1a 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -434,7 +434,9 @@ int ttm_bo_access(struct ttm_buffer_object *bo, unsigned long offset,
>  	if (ret)
>  		return ret;
>  
> -	switch (bo->resource->mem_type) {
> +	if (!bo->resource)
> +		ret = -ENODATA;
> +	else switch (bo->resource->mem_type) {

This is really odd style. I'd prefer:

if (!bo->resource) {
	ret = -ENODATA;
	goto unlock;
}

Matt

>  	case TTM_PL_SYSTEM:
>  		fallthrough;
>  	case TTM_PL_TT:
> -- 
> 2.47.3
>