Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1041899pxb; Fri, 22 Jan 2021 05:59:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJwGKm1JUb5UIefp/YhSYCxoYtaDOrQZFK2hl7gjlqOziPEjFUF5l0KNJa9Ewe3PWx6VIVij X-Received: by 2002:aa7:db96:: with SMTP id u22mr3403824edt.57.1611323950057; Fri, 22 Jan 2021 05:59:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611323950; cv=none; d=google.com; s=arc-20160816; b=SzwnBGDzYsyoSKskKXm2oyN5S43k8/RX0EgZW4N9A3t7+fdkqCD1/Ebd9Yc7749N28 /KhH1v12Z+fXv2mcuXjddop9NlnB9T0zgHGjqPMtmWx+MabhbmwYftfAc95Ete5CurEr /c2Ox5HNeVLW/7xZh6tEaix6j6qzmNuQHeYe20i7t1kccTsuFoJmiDroze3GDt0vU0FS OvBDMRG0CXsGfPRH8uCwFyU5DAle8cMNwMwVONC0iGawugGdazF4z2jTuZfezQ6issca vQsyO1Lzpd9XUK09PlCR2xjpBU9B9CuCLDRtyVctS/coURAe+BTut8Bju8g67lwZM8XP P8ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=VXLHixBiJpq4dDQEs6Gtzm6NcpCMBkU8X2Af5+47SP8=; b=lCdNqYc2jzbnnHPet33ZQ9EfG6FJgTZzb0JnhwjK2yc1N3AivAUf8dzDoNf8xtO/yc TyYsfqVsJrkNy7+lJ/Cv9T4t+JbMeTlnCk7HHuDp5TINipqRSHzjzyfCU8qACMUOWtz/ uIEF+dVdwHoUzweP0qBnJFfBgteq2748mhHKpH1jFmpOGm+165IwtjPq0EaHvLZ6CiUB atnGGSK+IFGhiICznolWM3yb0qHgJDXzdHIw9IeL40ng4xmn5bNxE8dkuCs4m0TzDR7p cHho9nTiCD1WTP6roe437BVNwX7qW1pdwh8NUtbc05ijPIezSG8U7H8ncdemVa3PXzzB 99aQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=fRMpTwPj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y22si3131742ejc.25.2021.01.22.05.58.43; Fri, 22 Jan 2021 05:59:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=fRMpTwPj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727519AbhAVNzp (ORCPT + 99 others); Fri, 22 Jan 2021 08:55:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44740 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727187AbhAVNzn (ORCPT ); Fri, 22 Jan 2021 08:55:43 -0500 Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0F3CC06174A for ; Fri, 22 Jan 2021 05:55:02 -0800 (PST) Received: by mail-oi1-x234.google.com with SMTP id q205so5974104oig.13 for ; Fri, 22 Jan 2021 05:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VXLHixBiJpq4dDQEs6Gtzm6NcpCMBkU8X2Af5+47SP8=; b=fRMpTwPjIHUaiFQn3JWCshKMbvL/9jw9UTg2r5aLKcTL6wI8i5Aeh+fcc5fL/Qw2dr 5mbSk7k9MXRDR/3PFkmwZsS9bakHodMpF6ufpYOGwwr3Kkxpe7KZY5pWhLhMuKeqOhYu Jj0Eb+R39koAF7xKwpPGpp19H95FqvvjmmP2I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VXLHixBiJpq4dDQEs6Gtzm6NcpCMBkU8X2Af5+47SP8=; b=ESe0TTrEbn4K05q0bsl5HkXfVtK2kr4CVXH4iy0IyOhioxjNlpDs+oCm7R4MqwdkX8 Q2vB68NZa9jrKoOHAqfpynNqw4+/klTti6SyYzawV6LpG+v2atnKDodrkhpAQwMTD8Up t5lP9hofw67QlHSUrJPoK1wddYKQfzSA+ZkP1DHPOxuMyipOlDB69MfuKPl6SuyroUj+ nK1/Bs3zeXUPyem2ZTxkyfiqf2Ax0MU9NVNlRRujo4G0wlOccSuM1tov2lqG1AzU02yp XVxqDtWlXauQXnIwXQ5BrbZi1Ojnctk5FxGm5pwB9ScDrcujt7SkYWR+rB+mYgEIHtz/ 0/tA== X-Gm-Message-State: AOAM531mTTNdVzMQJpBdCoz83do3hmygCpCm5uDJjWszlI7VPWvgn/A0 Z12dmmize08jarLnWTYiZcLSOK/me92046S5WSxhwg== X-Received: by 2002:aca:1906:: with SMTP id l6mr3220663oii.101.1611323702207; Fri, 22 Jan 2021 05:55:02 -0800 (PST) MIME-Version: 1.0 References: <20210120111240.2509679-1-kraxel@redhat.com> <20210120111240.2509679-3-kraxel@redhat.com> <20210122133545.acloe4ytgp6r4iql@sirius.home.kraxel.org> In-Reply-To: <20210122133545.acloe4ytgp6r4iql@sirius.home.kraxel.org> From: Daniel Vetter Date: Fri, 22 Jan 2021 14:54:51 +0100 Message-ID: Subject: Re: [PATCH v3 2/4] drm/qxl: unpin release objects To: Gerd Hoffmann Cc: Thomas Zimmermann , David Airlie , open list , dri-devel , "open list:DRM DRIVER FOR QXL VIRTUAL GPU" , Dave Airlie , "open list:DRM DRIVER FOR QXL VIRTUAL GPU" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 22, 2021 at 2:35 PM Gerd Hoffmann 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 > > > --- > > > 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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch