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 >
