From patchwork Mon Oct 26 13:10:19 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tvrtko Ursulin X-Patchwork-Id: 7488291 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 3DAB4BEEA4 for ; Mon, 26 Oct 2015 13:10:39 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 7555920700 for ; Mon, 26 Oct 2015 13:10:34 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 8F4C6206EF for ; Mon, 26 Oct 2015 13:10:30 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 99B4D6E4B7; Mon, 26 Oct 2015 06:10:26 -0700 (PDT) X-Original-To: Intel-gfx@lists.freedesktop.org Delivered-To: Intel-gfx@lists.freedesktop.org Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTP id 691036E4B7 for ; Mon, 26 Oct 2015 06:10:22 -0700 (PDT) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 26 Oct 2015 06:10:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,201,1444719600"; d="scan'208";a="588166743" Received: from tursulin-linux.isw.intel.com (HELO [10.102.226.89]) ([10.102.226.89]) by FMSMGA003.fm.intel.com with ESMTP; 26 Oct 2015 06:10:20 -0700 To: Chris Wilson , Intel-gfx@lists.freedesktop.org, Tvrtko Ursulin , Michel Thierry References: <1445857503-26621-1-git-send-email-tvrtko.ursulin@linux.intel.com> <20151026112307.GD21481@nuc-i3427.alporthouse.com> <562E15C6.1030304@linux.intel.com> <20151026121031.GE21481@nuc-i3427.alporthouse.com> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc Message-ID: <562E263B.2040307@linux.intel.com> Date: Mon, 26 Oct 2015 13:10:19 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151026121031.GE21481@nuc-i3427.alporthouse.com> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Ensure associated VMAs are inactive when contexts are destroyed X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 26/10/15 12:10, Chris Wilson wrote: > On Mon, Oct 26, 2015 at 12:00:06PM +0000, Tvrtko Ursulin wrote: >> >> On 26/10/15 11:23, Chris Wilson wrote: >>> On Mon, Oct 26, 2015 at 11:05:03AM +0000, Tvrtko Ursulin wrote: >>>> From: Tvrtko Ursulin >>>> >>>> In the following commit: >>>> >>>> commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae >>>> Author: Tvrtko Ursulin >>>> Date: Mon Oct 5 13:26:36 2015 +0100 >>>> >>>> drm/i915: Clean up associated VMAs on context destruction >>>> >>>> I added a WARN_ON assertion that VM's active list must be empty >>>> at the time of owning context is getting freed, but that turned >>>> out to be a wrong assumption. >>>> >>>> Due ordering of operations in i915_gem_object_retire__read, where >>>> contexts are unreferenced before VMAs are moved to the inactive >>>> list, the described situation can in fact happen. >>> >>> The context is being unreferenced indirectly. Adding a direct reference >>> here is even more bizarre. >> >> Perhaps is not the prettiest, but it sounds logical to me to ensure >> that order of destruction of involved object hierarchy goes from the >> bottom-up and is not interleaved. >> >> If you consider the active/inactive list position as part of the >> retire process, doing it at the very place in code, and the very >> object that looked to be destroyed out of sequence, to me sounded >> logical. >> >> How would you do it, can you think of a better way? > > The reference is via the request. We are handling requests, it makes > more sense that you take the reference on the request. Hm, so you would be happy with: > I would just revert the patch, it doesn't fix the problem you tried to > solve and just adds more. It solves one problem, just not all of them. Regards, Tvrtko diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 9b2048c7077d..c238481a8090 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2373,19 +2373,26 @@ static void i915_gem_object_retire__read(struct drm_i915_gem_object *obj, int ring) { struct i915_vma *vma; + struct drm_i915_gem_request *req; RQ_BUG_ON(obj->last_read_req[ring] == NULL); RQ_BUG_ON(!(obj->active & (1 << ring))); list_del_init(&obj->ring_list[ring]); + + /* Ensure context cannot be destroyed with VMAs on the active list. */ + req = i915_gem_request_reference(obj->last_read_req[ring]); + i915_gem_request_assign(&obj->last_read_req[ring], NULL); if (obj->last_write_req && obj->last_write_req->ring->id == ring) i915_gem_object_retire__write(obj); obj->active &= ~(1 << ring); - if (obj->active) + if (obj->active) { + i915_gem_request_unreference(req); return; + } /* Bump our place on the bound list to keep it roughly in LRU order * so that we don't steal from recently used but inactive objects @@ -2399,6 +2406,8 @@ i915_gem_object_retire__read(struct drm_i915_gem_object *obj, int ring) list_move_tail(&vma->mm_list, &vma->vm->inactive_list); } + i915_gem_request_unreference(req); + i915_gem_request_assign(&obj->last_fenced_req, NULL); drm_gem_object_unreference(&obj->base); }