Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1639689ybz; Sun, 26 Apr 2020 00:53:34 -0700 (PDT) X-Google-Smtp-Source: APiQypJFhHYL3DX5dJBn+o8Lu5S+g7yuJyJWkH/OiaAjBf+jHrlM/o2pzKA8vBLw/WECRJ+ATGNl X-Received: by 2002:a05:6402:b4e:: with SMTP id bx14mr14601706edb.41.1587887614106; Sun, 26 Apr 2020 00:53:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587887614; cv=none; d=google.com; s=arc-20160816; b=VuCnpwI+6gSmps+nRyhDDdJP9THaC1iCa6df1OQqkQWUf1Jvz3Qzd5P55VfGlxvT9U F4Z4vBF6OcXYoI+iUmk7X2otWG2LmmPr12BZrlmoKtW2pz7SJv5ZBr6yWjoxT1dBjtah 9s0SEglP+Be0TZhrdtzon1yieiwirpO2EeFitMOJYXWbmFTfgIehRkrW7sCxWFMPFPLz 2fWhLa+UekHYbdZSOSnbY7nsIV8KhKyQqMmktscNV/au6ZobPYi2+Qb0TDrqAniqKfgI 8NuIag2iIkkG+sePtwGWYHDiXbJotHQfcBcSMT3S1qsTjLArn/p1K1ieen029I5iN8Ap 8dIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:cc:from:references:to:subject; bh=Od67HNGrKKCpHp/HzhvqYRnWtPesvsuqkQxg2qRccwA=; b=iNUxLs83bQ5gIRjW8Xl5RPEU5JJjg5X3V/5ZEe71o3+sG4PKKWdDnB2YwkKix/+ATf bBtmA0P4AeHm9aIsiqIsnTrbfpXUrCme/brptSU5b1whk9encpqv1MmeWNGpvaDCrR0J 1P1IIAA4bSiN0EnTfVjrY6p/88SEsRU/xeEkfI/+27f3Q6I0jIAmS4MefVYl4oM3HjnA 2SLEZENMQWlQVC0DBI0qq41B52k+vodx9ABLrOaaQV2kWz0SIPq5IL19tjPppx/VcP8g wHnA//qWo+kOFjCFhYvOOC4d5K04MKdgz9eYdk5viuOLGOXQY+0XNmS7+j+VoXVfAekV 5elQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y5si6050174ede.173.2020.04.26.00.53.11; Sun, 26 Apr 2020 00:53:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726217AbgDZHvu (ORCPT + 99 others); Sun, 26 Apr 2020 03:51:50 -0400 Received: from relay.sw.ru ([185.231.240.75]:60556 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726154AbgDZHvt (ORCPT ); Sun, 26 Apr 2020 03:51:49 -0400 Received: from vvs-ws.sw.ru ([172.16.24.21]) by relay.sw.ru with esmtp (Exim 4.92.3) (envelope-from ) id 1jSc4V-0002AX-S7; Sun, 26 Apr 2020 10:51:28 +0300 Subject: Re: [PATCH 1/1] drm/qxl: add mutex_lock/mutex_unlock to ensure the order in which resources are released To: Caicai , Dave Airlie References: <20200418063917.26278-1-caizhaopeng () uniontech ! com> From: Vasily Averin Cc: Gerd Hoffmann , David Airlie , virtualization@lists.linux-foundation.org, dri-devel@lists.freedesktop.org, "linux-kernel@vger.kernel.org" , Zhangyueqian Message-ID: <5488290f-fe60-874e-2b18-0327e877fdbc@virtuozzo.com> Date: Sun, 26 Apr 2020 10:51:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200418063917.26278-1-caizhaopeng () uniontech ! com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/18/20 9:39 AM, Caicai wrote: > When a qxl resource is released, the list that needs to be released is > fetched from the linked list ring and cleared. When you empty the list, > instead of trying to determine whether the ttm buffer object for each > qxl in the list is locked, you release the qxl object and remove the > element from the list until the list is empty. It was found that the > linked list was cleared first, and that the lock on the corresponding > ttm Bo for the QXL had not been released, so that the new qxl could not > be locked when it used the TTM. By adding an additional mutex to ensure > timing, qxl elements are not allowed to be removed from the list until > ttm Bo's lock is released > @@ -241,7 +243,11 @@ int qxl_garbage_collect(struct qxl_device *qdev) > } > id = next_id; > > + mutex_lock(&release->async_release_mutex); > + > qxl_release_free(qdev, release); > + > + mutex_unlock(&release->async_release_mutex); It does not work, release was freed inside qxl_release_free() so you cannot access here any its fields > ++i; > } > }