From: Vasily Averin <vvs@virtuozzo.com>
To: Caicai <caizhaopeng@uniontech.com>, Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
David Airlie <airlied@linux.ie>,
virtualization@lists.linux-foundation.org,
dri-devel@lists.freedesktop.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Zhangyueqian <zhangyueqian@uniontech.com>
Subject: Re: [PATCH 1/1] drm/qxl: add mutex_lock/mutex_unlock to ensure the order in which resources are released
Date: Sun, 26 Apr 2020 10:51:27 +0300 [thread overview]
Message-ID: <5488290f-fe60-874e-2b18-0327e877fdbc@virtuozzo.com> (raw)
In-Reply-To: <20200418063917.26278-1-caizhaopeng () uniontech ! com>
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;
> }
> }
next parent reply other threads:[~2020-04-26 7:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200418063917.26278-1-caizhaopeng () uniontech ! com>
2020-04-26 7:51 ` Vasily Averin [this message]
2020-04-18 6:39 Caicai
2020-04-21 8:43 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5488290f-fe60-874e-2b18-0327e877fdbc@virtuozzo.com \
--to=vvs@virtuozzo.com \
--cc=airlied@linux.ie \
--cc=airlied@redhat.com \
--cc=caizhaopeng@uniontech.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=zhangyueqian@uniontech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®