From patchwork Tue Jun 14 18:43:45 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ramalingam C X-Patchwork-Id: 12881366 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 0D856CCA47B for ; Tue, 14 Jun 2022 18:42:28 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0E90F10EF3F; Tue, 14 Jun 2022 18:42:21 +0000 (UTC) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id A055910E2E1; Tue, 14 Jun 2022 18:42:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655232139; x=1686768139; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=UZlbeoSxpAp/5XwDP4Hz2JX1/02hBNoVQ9fDD24zb1Y=; b=d2Rny8SdpAzyGj317tx4ZaW4AP4hyrvQo0D3PxmmSNvffDR5dnQjV0LM 6PB729zTbC0WNk+TuSPcembBv9StV6AEp/S6Q42RJhXeWSkB7PJYrnsRv 0oq0OUIzWRCQO/WdMr1kWxKNC/vmpa/JXBxCyvwxTpp4sdPpzhJAMl0KV 5DYmGDI5fFh8RBUPyx/hUGR5ChMWD+7YgewdtFM25hGNVNfwdfl3eXuh5 R/08LxcGPoXC+7HOr3Hh5GISDHa4V8YPTw01GtBo7FvFsJQBumcLZtDvP TBxbIBFEWDcSZYHKlvLImyU0qFvcszqspM2zem5ZdNmbbbLZOjBXN7E2j g==; X-IronPort-AV: E=McAfee;i="6400,9594,10378"; a="279426405" X-IronPort-AV: E=Sophos;i="5.91,300,1647327600"; d="scan'208";a="279426405" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jun 2022 11:42:19 -0700 X-IronPort-AV: E=Sophos;i="5.91,300,1647327600"; d="scan'208";a="588627286" Received: from ramaling-i9x.iind.intel.com ([10.203.144.108]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jun 2022 11:42:16 -0700 From: Ramalingam C To: intel-gfx , dri-devel Date: Wed, 15 Jun 2022 00:13:45 +0530 Message-Id: <20220614184348.23746-1-ramalingam.c@intel.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH 0/3] Break VM to rq reference loop 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: Hellstrom Thomas , Matthew Auld Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" The i915_request holds a reference to intel_context, which in turn holds a reference on the VM. But the dma-resv update for VM_BIND feature would require VM hold a reference to the i915_request through dma-resv fences of VM_PRIVATE objects (which share a per VM dma-resv object). Thus, we have a circular reference pattern causing the VM reference to never reach 0, hence VM is not destroyed. Break this by reverting the below patch which is making the i915_request to hold a reference on intel_context. "drm/i915: Hold reference to intel_context over life of i915_request" This means we can't access rq->engine in i915_fence_get_driver_name() as user do not hold a reference on rq->engine here. So, instead store required device private pointer in 'rq->i915' and use it. Niranjana Vishwanathapura (2): drm/i915: Do not access rq->engine without a reference Revert "drm/i915: Hold reference to intel_context over life of i915_request" Ramalingam C (1): drm/i915: Do not use reserved requests for virtual engines drivers/gpu/drm/i915/i915_request.c | 55 ++++++++++++++++++----------- drivers/gpu/drm/i915/i915_request.h | 2 ++ 2 files changed, 36 insertions(+), 21 deletions(-)