From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A504C4743F for ; Tue, 8 Jun 2021 06:56:07 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 05F9A60FF4 for ; Tue, 8 Jun 2021 06:56:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 05F9A60FF4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2E66D6EAB0; Tue, 8 Jun 2021 06:56:02 +0000 (UTC) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by gabe.freedesktop.org (Postfix) with ESMTPS id 655F86EAB1 for ; Tue, 8 Jun 2021 06:56:00 +0000 (UTC) IronPort-SDR: LmZLupIYSRWWquLdzHJWNmcRwRh8KOltObWr/klZLV0pfL7R9eKMdF6bwnMOixNJ61/3a6mQE1 hxX2XMDT9koQ== X-IronPort-AV: E=McAfee;i="6200,9189,10008"; a="268637942" X-IronPort-AV: E=Sophos;i="5.83,257,1616482800"; d="scan'208";a="268637942" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2021 23:55:58 -0700 IronPort-SDR: B1dzXudDSOu9xfwx84Qgj3FKidsgyLzEnrPAsEb6+rxN48ZlbY+TEpjIfu8OlvZaHuTeYqGe1t jOg2GZ4vEyYA== X-IronPort-AV: E=Sophos;i="5.83,257,1616482800"; d="scan'208";a="634974036" Received: from delmer-mobl.ger.corp.intel.com (HELO [10.249.254.231]) ([10.249.254.231]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2021 23:55:56 -0700 Subject: Re: [PATCH 01/10] drm/ttm: allocate resource object instead of embedding it v2 To: =?UTF-8?Q?Christian_K=c3=b6nig?= , matthew.auld@intel.com, dri-devel@lists.freedesktop.org References: <20210602100914.46246-1-christian.koenig@amd.com> From: =?UTF-8?Q?Thomas_Hellstr=c3=b6m?= Message-ID: Date: Tue, 8 Jun 2021 08:55:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <20210602100914.46246-1-christian.koenig@amd.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi, On 6/2/21 12:09 PM, Christian König wrote: > To improve the handling we want the establish the resource object as base > class for the backend allocations. > > v2: add missing error handling > > Signed-off-by: Christian König > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 54 +++++++------- > drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +- > drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- > drivers/gpu/drm/ttm/ttm_bo.c | 83 ++++++++-------------- > drivers/gpu/drm/ttm/ttm_bo_util.c | 43 ++++++----- > drivers/gpu/drm/ttm/ttm_resource.c | 31 +++++--- > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +- > include/drm/ttm/ttm_bo_api.h | 1 - > include/drm/ttm/ttm_bo_driver.h | 10 ++- > include/drm/ttm/ttm_resource.h | 4 +- > 11 files changed, 110 insertions(+), 126 deletions(-) ... > > @@ -629,7 +628,7 @@ static void ttm_bo_move_pipeline_evict(struct ttm_buffer_object *bo, > } > spin_unlock(&from->move_lock); > > - ttm_resource_free(bo, bo->resource); > + ttm_resource_free(bo, &bo->resource); > > dma_fence_put(bo->moving); > bo->moving = dma_fence_get(fence); > @@ -678,11 +677,11 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo) > if (ret) > ttm_bo_wait(bo, false, false); > > - ttm_resource_alloc(bo, &sys_mem, bo->resource); > + ret = ttm_resource_alloc(bo, &sys_mem, &bo->resource); > bo->ttm = NULL; > > dma_resv_unlock(&ghost->base._resv); > ttm_bo_put(ghost); > > - return 0; > + return ret; Here we re-introduce a late point of failure, which I guess leaves the bo in an undefined state? Same thing with my optimization for the idle case. Needs fixing as soon as possible. /Thomas