[<prev] [next>] [day] [month] [year] [list]
Message-ID: <5488290f-fe60-874e-2b18-0327e877fdbc@virtuozzo.com>
Date: Sun, 26 Apr 2020 10:51:27 +0300
From: Vasily Averin <vvs@...tuozzo.com>
To: Caicai <caizhaopeng@...ontech.com>,
Dave Airlie <airlied@...hat.com>
Cc: Gerd Hoffmann <kraxel@...hat.com>, David Airlie <airlied@...ux.ie>,
virtualization@...ts.linux-foundation.org,
dri-devel@...ts.freedesktop.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Zhangyueqian <zhangyueqian@...ontech.com>
Subject: Re: [PATCH 1/1] drm/qxl: add mutex_lock/mutex_unlock to ensure the
order in which resources are released
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;
> }
> }
Powered by blists - more mailing lists