I guess this because you move the resv changing out of lock of bo->resv. Because at the beginning ttm_mem_evict_first may __ttm_bo_reserve(bo->resv) success, and then bo->resv has been changed by another thread. That is not matched and at this point bo->ttm_resv also may been freed already.
And I think it is not easy to put it out of two lock of bo->resv and bo->ttm_resv. Thanks Roger(Hongbo.He) -----Original Message----- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Michel D?nzer Sent: Wednesday, November 08, 2017 12:16 AM To: Christian König <ckoenig.leichtzumer...@gmail.com> Cc: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/ttm: set bo->resv point to tbo->ttm_resv after individualize_resv On 07/11/17 02:44 PM, Christian König wrote: > Set bo->resv to ttm_resv during BO cleanup. This way freed BOs can be > better reaped during eviction. > > Signed-off-by: Roger He <hongbo...@amd.com> > Signed-off-by: Christian König <christian.koe...@amd.com> KASAN caught some badness while running piglit with this applied, see the attached dmesg excerpts. At least some of this might be pre-existing bugs being exposed by this change. E.g. I've been chasing another use-after-free, with ttm_bo_delayed_delete trying to reserve a BO which has already been destroyed. Looks like maybe the ddestroy list handling isn't quite watertight yet. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
