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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 0B447C636D7 for ; Tue, 21 Feb 2023 16:13:42 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9F2E710E32F; Tue, 21 Feb 2023 16:13:40 +0000 (UTC) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id 405E010E32F; Tue, 21 Feb 2023 16:13:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1676996017; x=1708532017; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=9ErA5NeibbBy1VenkBrKsnlZXjRiiFRc6RowtBw6qiw=; b=gefWmw4W5iRxiEkUkK0YDWAky0mBz2zinKLKweLievyIG9FnWu3zN8WX K0F3ZQU3gDJ/+dvnjXiHwXS8mE5tA6msBqFOB1waIw6k9KzYybbVumkxd 7EAewwP6K0Wks7XhgNDJr39jM+n3p1wJtQpZoka2b0yFkEX7MpWbUaYeN Hil8jexeIiU4V8NWNwxTGof5tkLYWpCqDQvz4F/TdtcQUK44g2tWLS2wB Bl1Yp0MLVl73GFKsC9/vK/MwMeRcjvcft813QwANG+qf8G7cuZDogYGDj GFpZKQ2jdrDFLL79bCat/WEwX6KWWoUUB6mt+S5saUcK4SkU/nKJr1tOb A==; X-IronPort-AV: E=McAfee;i="6500,9779,10628"; a="312303466" X-IronPort-AV: E=Sophos;i="5.97,315,1669104000"; d="scan'208";a="312303466" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Feb 2023 08:13:36 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10628"; a="845728013" X-IronPort-AV: E=Sophos;i="5.97,315,1669104000"; d="scan'208";a="845728013" Received: from tcollin2-mobl.ger.corp.intel.com (HELO [10.252.18.163]) ([10.252.18.163]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Feb 2023 08:13:35 -0800 Message-ID: Date: Tue, 21 Feb 2023 16:13:33 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.7.1 Content-Language: en-GB To: =?UTF-8?Q?Christian_K=c3=b6nig?= , intel-gfx@lists.freedesktop.org References: <20230208145319.397235-1-matthew.auld@intel.com> <03b9cbee-e453-255b-923c-6b116b9e2cf1@amd.com> From: Matthew Auld In-Reply-To: <03b9cbee-e453-255b-923c-6b116b9e2cf1@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Intel-gfx] [PATCH 1/4] drm/gem-vram: handle NULL bo->resource in move callback X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: dri-devel@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On 10/02/2023 11:03, Christian König wrote: > Am 08.02.23 um 15:53 schrieb Matthew Auld: >> The ttm BO now initially has NULL bo->resource, and leaves the driver >> the handle that. However it looks like we forgot to handle that for >> ttm_bo_move_memcpy() users, like with vram-gem, since it just silently >> returns zero. This seems to then trigger warnings like: >> >> WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_gem_vram_helper.c:255 >> drm_gem_vram_offset (??:?) >> >> Fix this by calling move_null() if the new resource is TTM_PL_SYSTEM, >> otherwise do the multi-hop sequence to ensure can safely call into >> ttm_bo_move_memcpy(), since it might also need to clear the memory. >> This should give the same behaviour as before. >> >> While we are here let's also treat calling ttm_bo_move_memcpy() with >> NULL bo->resource as programmer error, where expectation is that upper >> layers should now handle it. >> >> Fixes: 180253782038 ("drm/ttm: stop allocating dummy resources during >> BO creation") >> Signed-off-by: Matthew Auld >> Cc: Christian König > > Oh, I wasn't aware that this broke at so many places. Especially radeon > was tested earlier in the development of the patch set. > > Thanks for looking into that, the radeon patch has my rb and the rest of > the series is Acked-by: Christian König . Should we go ahead and land this? (minus patch 3 since that is already fixed by vmware folks). > > Regards, > Christian. > >> --- >>   drivers/gpu/drm/drm_gem_vram_helper.c | 11 +++++++++++ >>   drivers/gpu/drm/ttm/ttm_bo_util.c     |  4 ++-- >>   2 files changed, 13 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c >> b/drivers/gpu/drm/drm_gem_vram_helper.c >> index d40b3edb52d0..0bea3df2a16d 100644 >> --- a/drivers/gpu/drm/drm_gem_vram_helper.c >> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c >> @@ -916,6 +916,17 @@ static int bo_driver_move(struct >> ttm_buffer_object *bo, >>   { >>       struct drm_gem_vram_object *gbo; >> +    if (!bo->resource) { >> +        if (new_mem->mem_type != TTM_PL_SYSTEM) { >> +            hop->mem_type = TTM_PL_SYSTEM; >> +            hop->flags = TTM_PL_FLAG_TEMPORARY; >> +            return -EMULTIHOP; >> +        } >> + >> +        ttm_bo_move_null(bo, new_mem); >> +        return 0; >> +    } >> + >>       gbo = drm_gem_vram_of_bo(bo); >>       return drm_gem_vram_bo_driver_move(gbo, evict, ctx, new_mem); >> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c >> b/drivers/gpu/drm/ttm/ttm_bo_util.c >> index d9d2b0903b22..fd9fd3d15101 100644 >> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c >> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c >> @@ -157,8 +157,8 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo, >>       bool clear; >>       int ret = 0; >> -    if (!src_mem) >> -        return 0; >> +    if (WARN_ON(!src_mem)) >> +        return -EINVAL; >>       src_man = ttm_manager_type(bdev, src_mem->mem_type); >>       if (ttm && ((ttm->page_flags & TTM_TT_FLAG_SWAPPED) || >