From patchwork Wed Feb 8 14:53:16 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Matthew Auld X-Patchwork-Id: 13133125 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 3C490C05027 for ; Wed, 8 Feb 2023 14:57:28 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CE49310E7A7; Wed, 8 Feb 2023 14:57:24 +0000 (UTC) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id D1DAD10E7A7; Wed, 8 Feb 2023 14:57:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675868241; x=1707404241; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=kEW+4ZCMPZv85JnRlMwAygJ7zE/yoIahsudEfBAJaM0=; b=jxke0MkTlYYlY/5jAOEPuWs2fhumMcvJIDeEYAyoVdw7PsQXVdLkdJC6 df12DiHfWuO7k0fYfdig8T/vmAxjsorxlBl7dQ5KeyV8WtXNc2KEy1swV XM7kDi/Blx74CcfNDyt4lTbvtCq/MGJbRHohA3PnckM+R3XvNtivo1eTe uC96Lz357mRmWxl4cqA8jIdf9zb+9BwEbAaiOoucvcvIqyFLxZAkyIf5U dMeTdjvunpfaMv9IW37sxil6tcFrI0xsaiW1Mmo4jKU73dbOgEp0q/kmQ A+R3zAb+J+O+UX4dJnVjbsHPVZSS8fa8CILmbAP7868pWZt2X78uK3KNM A==; X-IronPort-AV: E=McAfee;i="6500,9779,10615"; a="328469187" X-IronPort-AV: E=Sophos;i="5.97,281,1669104000"; d="scan'208";a="328469187" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2023 06:57:21 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10615"; a="617233445" X-IronPort-AV: E=Sophos;i="5.97,281,1669104000"; d="scan'208";a="617233445" Received: from hassanka-mobl1.ger.corp.intel.com (HELO mwauld-desk1.intel.com) ([10.252.31.252]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2023 06:57:19 -0800 From: Matthew Auld To: intel-gfx@lists.freedesktop.org Date: Wed, 8 Feb 2023 14:53:16 +0000 Message-Id: <20230208145319.397235-1-matthew.auld@intel.com> X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 Subject: [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: =?utf-8?q?Christian_K=C3=B6nig?= , dri-devel@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" 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 --- 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) || From patchwork Wed Feb 8 14:53:17 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Matthew Auld X-Patchwork-Id: 13133126 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 E4B65C636CC for ; Wed, 8 Feb 2023 14:57:29 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 20A5C10E7AF; Wed, 8 Feb 2023 14:57:25 +0000 (UTC) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0EE0D10E7A7; Wed, 8 Feb 2023 14:57:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675868243; x=1707404243; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=opTd8+G1Y/rtR2GCvHtLEXdoN8IPXeYAezj4yEWDy54=; b=gkvdA/xWwJc1xD2u5YmvDGO/oR+sOAuXiXheBwPVoRn/8rQxOlgSSFmZ A+92MLOS9dqu4g4aND/S8L8XhflpAI0PRKbtBmym4ScOKk0cHsleMBq1E 4+85MOkK8j2qTwogrsl6u9SPa5TxypzlHEd1LlNRPrP4r1JD3qAn885GK XPyFP3uvXopf6ytD/0MQ/JYbAyvhHHVzkWjF7xUPkRLPHTRIl1jGcyAT3 iKM7fREJe6vkHiB7nTFsKT9x10/WfKRSSq/Xn5T+1YtQNppDHVCGVxk4L LJOT8eKkzHpF7bAflm8DP0FOu2ermS+YiT1i1qBhExcoGXOEMIJySNT4H Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10615"; a="328469192" X-IronPort-AV: E=Sophos;i="5.97,281,1669104000"; d="scan'208";a="328469192" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2023 06:57:22 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10615"; a="617233448" X-IronPort-AV: E=Sophos;i="5.97,281,1669104000"; d="scan'208";a="617233448" Received: from hassanka-mobl1.ger.corp.intel.com (HELO mwauld-desk1.intel.com) ([10.252.31.252]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2023 06:57:21 -0800 From: Matthew Auld To: intel-gfx@lists.freedesktop.org Date: Wed, 8 Feb 2023 14:53:17 +0000 Message-Id: <20230208145319.397235-2-matthew.auld@intel.com> X-Mailer: git-send-email 2.39.1 In-Reply-To: <20230208145319.397235-1-matthew.auld@intel.com> References: <20230208145319.397235-1-matthew.auld@intel.com> MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH 2/4] drm/qxl: 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: =?utf-8?q?Christian_K=C3=B6nig?= , dri-devel@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" 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 qxl. It looks like this will just null-ptr-deref in qxl_bo_move(), if bo->resource is NULL. 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. Fixes: 180253782038 ("drm/ttm: stop allocating dummy resources during BO creation") Signed-off-by: Matthew Auld Cc: Christian König --- drivers/gpu/drm/qxl/qxl_ttm.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c index a92a5b0d4c25..1a82629bce3f 100644 --- a/drivers/gpu/drm/qxl/qxl_ttm.c +++ b/drivers/gpu/drm/qxl/qxl_ttm.c @@ -143,6 +143,17 @@ static int qxl_bo_move(struct ttm_buffer_object *bo, bool evict, struct ttm_resource *old_mem = bo->resource; int ret; + if (!old_mem) { + 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; + } + qxl_bo_move_notify(bo, new_mem); ret = ttm_bo_wait_ctx(bo, ctx); From patchwork Wed Feb 8 14:53:18 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Matthew Auld X-Patchwork-Id: 13133127 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 47638C636D4 for ; Wed, 8 Feb 2023 14:57:31 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2349D10E7B1; Wed, 8 Feb 2023 14:57:27 +0000 (UTC) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5416610E7A7; Wed, 8 Feb 2023 14:57:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675868244; x=1707404244; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=1jBQnamuvrY/gPkX5IHbAcUeF1i/cYoDD6ngz7qXJt4=; b=HKSjjutGGve02ZEiu9agTBKCIrtfJr/+RUhJbDketiaPEOev9GqsRT/F wv3LHOVpzGTEfNK7+rRqyiFJKCbSzf7NNKmVgGCo+4AujQf68fc+A+enR 272MUA6GhlPptkRGQS85wnB3qxCcdMoqk1rm4hibS7wUbi+J8jfh5l2Uk phlSG219KBUKWJhV2GThCFxENQjzBGj/GehUlKGSFmRpUW9CkFAbLvDtK dlO07jfPrtmPpaiI7/XknzWk9DffyaSuaYYDWgwd1CywS42j0/vdPR3o2 KJtsgkoarrL25SaaUREd1aIFxmNA4m8d0UGJzNQfJ/m1WN7U0lWsld/bJ w==; X-IronPort-AV: E=McAfee;i="6500,9779,10615"; a="328469198" X-IronPort-AV: E=Sophos;i="5.97,281,1669104000"; d="scan'208";a="328469198" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2023 06:57:24 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10615"; a="617233449" X-IronPort-AV: E=Sophos;i="5.97,281,1669104000"; d="scan'208";a="617233449" Received: from hassanka-mobl1.ger.corp.intel.com (HELO mwauld-desk1.intel.com) ([10.252.31.252]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2023 06:57:22 -0800 From: Matthew Auld To: intel-gfx@lists.freedesktop.org Date: Wed, 8 Feb 2023 14:53:18 +0000 Message-Id: <20230208145319.397235-3-matthew.auld@intel.com> X-Mailer: git-send-email 2.39.1 In-Reply-To: <20230208145319.397235-1-matthew.auld@intel.com> References: <20230208145319.397235-1-matthew.auld@intel.com> MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH 3/4] drm/vmwgfx: 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: =?utf-8?q?Christian_K=C3=B6nig?= , dri-devel@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" 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 vmwgfx. It looks like this will just null-ptr-deref in vmw_move(), if bo->resource is NULL. 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. Fixes: 180253782038 ("drm/ttm: stop allocating dummy resources during BO creation") Signed-off-by: Matthew Auld Cc: Christian König --- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c index 856a352a72a6..c598c5a9fe2c 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c @@ -596,10 +596,23 @@ static int vmw_move(struct ttm_buffer_object *bo, struct ttm_resource *new_mem, struct ttm_place *hop) { - struct ttm_resource_manager *old_man = ttm_manager_type(bo->bdev, bo->resource->mem_type); + struct ttm_resource_manager *old_man; struct ttm_resource_manager *new_man = ttm_manager_type(bo->bdev, new_mem->mem_type); int ret; + 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; + } + + old_man = ttm_manager_type(bo->bdev, bo->resource->mem_type); + if (new_man->use_tt && !vmw_memtype_is_system(new_mem->mem_type)) { ret = vmw_ttm_bind(bo->bdev, bo->ttm, new_mem); if (ret) From patchwork Wed Feb 8 14:53:19 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Matthew Auld X-Patchwork-Id: 13133128 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 11FD6C636D4 for ; Wed, 8 Feb 2023 14:57:38 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id F117710E7B3; Wed, 8 Feb 2023 14:57:30 +0000 (UTC) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id CB3BB10E7B0; Wed, 8 Feb 2023 14:57:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675868245; x=1707404245; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=uV7AgTbrch/Eu7LxtX7piER6N6FgL/dvdUlPwqpriz0=; b=IqAgXwVtJIwpCdvv6s84vAZxUbU+FFGBx6YpekR+UbsIGOnGCVE2PO9B tojRLEnUQALkBE2jjUGMe4WW7kElM4lNGmLXTwpnD8xcK5WokdhxC1qSq 9OEmttkF2m/hjVHj6Kkkok70ymehu4+PcmQ0S+YkWQrZk1JgNRTSD+56I MOYd2I7qR/RaJ43e1r0y8SW+P7VfMXRg39hXBZhOI7z4Wknt7UEsgjL/u UtrX4igatqUAk0VzFsJu86ZBWhfQy37GpD/mzmwW4JNwdbU5vhfvuUtjn cUo/sCykg35B2SLoaUew+UszJKS5W2+M+UFglIWqDXrEggqHqhvirZ0VE A==; X-IronPort-AV: E=McAfee;i="6500,9779,10615"; a="328469205" X-IronPort-AV: E=Sophos;i="5.97,281,1669104000"; d="scan'208";a="328469205" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2023 06:57:25 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10615"; a="617233452" X-IronPort-AV: E=Sophos;i="5.97,281,1669104000"; d="scan'208";a="617233452" Received: from hassanka-mobl1.ger.corp.intel.com (HELO mwauld-desk1.intel.com) ([10.252.31.252]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2023 06:57:24 -0800 From: Matthew Auld To: intel-gfx@lists.freedesktop.org Date: Wed, 8 Feb 2023 14:53:19 +0000 Message-Id: <20230208145319.397235-4-matthew.auld@intel.com> X-Mailer: git-send-email 2.39.1 In-Reply-To: <20230208145319.397235-1-matthew.auld@intel.com> References: <20230208145319.397235-1-matthew.auld@intel.com> MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH 4/4] drm/radeon: 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: =?utf-8?q?Christian_K=C3=B6nig?= , dri-devel@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" 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 radeon. It looks like this will just null-ptr-deref in radeon_bo_move(), if bo->resource is NULL. Fix this by calling move_null(). Fixes: 180253782038 ("drm/ttm: stop allocating dummy resources during BO creation") Signed-off-by: Matthew Auld Cc: Christian König --- drivers/gpu/drm/radeon/radeon_ttm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 67075c85f847..2220cdf6a3f6 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -213,7 +213,8 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, bool evict, rbo = container_of(bo, struct radeon_bo, tbo); rdev = radeon_get_rdev(bo->bdev); - if (old_mem->mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) { + if (!old_mem || (old_mem->mem_type == TTM_PL_SYSTEM && + bo->ttm == NULL)) { ttm_bo_move_null(bo, new_mem); goto out; }