On Fri, Jan 22, 2021 at 2:35 PM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > On Fri, Jan 22, 2021 at 09:13:42AM +0100, Thomas Zimmermann wrote: > > Hi > > > > Am 20.01.21 um 12:12 schrieb Gerd Hoffmann: > > > Balances the qxl_create_bo(..., pinned=true, ...); > > > call in qxl_release_bo_alloc(). > > > > > > Signed-off-by: Gerd Hoffmann <kraxel@xxxxxxxxxx> > > > --- > > > drivers/gpu/drm/qxl/qxl_release.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/drivers/gpu/drm/qxl/qxl_release.c b/drivers/gpu/drm/qxl/qxl_release.c > > > index 0fcfc952d5e9..add979cba11b 100644 > > > --- a/drivers/gpu/drm/qxl/qxl_release.c > > > +++ b/drivers/gpu/drm/qxl/qxl_release.c > > > @@ -166,6 +166,7 @@ qxl_release_free_list(struct qxl_release *release) > > > entry = container_of(release->bos.next, > > > struct qxl_bo_list, tv.head); > > > bo = to_qxl_bo(entry->tv.bo); > > > + bo->tbo.pin_count = 0; /* ttm_bo_unpin(&bo->tbo); */ > > > > This code looks like a workaround or a bug. > > > > AFAICT the only place with pre-pinned BO is qdev->dumb_shadow_bo. Can you > > remove the pinned flag entirely and handle pinning as part of > > dumb_shadow_bo's code. > > No, the release objects are pinned too, and they must be > pinned (qxl commands are in there, and references are > placed in the qxl rings, so allowing them to roam is > a non-starter). > > > if (pin_count) > > ttm_bo_unpin(); > > WARN_ON(pin_count); /* should always be 0 now */ > > Well, the pin_count is 1 at this point. > No need for the if(). > > Just calling ttm_bo_unpin() here makes lockdep unhappy. How does that one splat? But yeah if that's a problem should be explained in the comment. I'd then also only do a pin_count--; to make sure you can still catch other pin leaks if you have them. Setting it to 0 kinda defeats the warning. -Daniel > > Not calling ttm_bo_unpin() makes ttm_bo_release() throw > a WARN() because of the pin. > > Clearing pin_count (which is how ttm fixes things up > in the error path) works. > > I'm open to better ideas. > > take care, > Gerd > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
