On Thu, 1 Jul 2021 at 10:39, Matthew Auld <matthew.william.auld@xxxxxxxxx> wrote: > > On Mon, 28 Jun 2021 at 15:49, Bommu Krishnaiah > <krishnaiah.bommu@xxxxxxxxx> wrote: > > > > Signed-off-by: Bommu Krishnaiah <krishnaiah.bommu@xxxxxxxxx> > > Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> > > --- > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > index c39d982c4fa66..97093a9bfccc2 100644 > > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > @@ -590,6 +590,7 @@ static unsigned long i915_ttm_io_mem_pfn(struct ttm_buffer_object *bo, > > GEM_WARN_ON(bo->ttm); > > > > sg = __i915_gem_object_get_sg(obj, &obj->ttm.get_io_page, page_offset, &ofs, true, true); > > + GEM_BUG_ON(!sg); > > Is there some analysis for how this could happen? The commit message > should ideally have something like that. It looks like we already have > a GEM_BUG_ON(!sg) for the lookup case, and in the event of doing the > manual walk we already dereference the sg, so not seeing it. So simply adding GEM_BUG_ON(!sg) here I don't think does anything. But maybe this tool is trying to point out a potential bug inside __i915_gem_object_get_sg(), hence needs proper analysis. > > > > > return ((base + sg_dma_address(sg)) >> PAGE_SHIFT) + ofs; > > } > > -- > > 2.25.1 > > > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx