From: Juergen Gross <jgross@suse.com>
To: "Demi Marie Obenour" <demi@invisiblethingslab.com>,
"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Jennifer Herbert" <jennifer.herbert@citrix.com>,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v2] xen/gntdev: Avoid blocking in unmap_grant_pages()
Date: Mon, 30 May 2022 08:41:20 +0200 [thread overview]
Message-ID: <00c0b10c-a35d-6729-5b4f-424febd9d5a3@suse.com> (raw)
In-Reply-To: <20220525184153.6059-1-demi@invisiblethingslab.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 2240 bytes --]
On 25.05.22 20:41, Demi Marie Obenour wrote:
> unmap_grant_pages() currently waits for the pages to no longer be used.
> In https://github.com/QubesOS/qubes-issues/issues/7481, this lead to a
> deadlock against i915: i915 was waiting for gntdev's MMU notifier to
> finish, while gntdev was waiting for i915 to free its pages. I also
> believe this is responsible for various deadlocks I have experienced in
> the past.
>
> Avoid these problems by making unmap_grant_pages async. This requires
> making it return void, as any errors will not be available when the
> function returns. Fortunately, the only use of the return value is a
> WARN_ON(), which can be replaced by a WARN_ON when the error is
> detected. Additionally, a failed call will not prevent further calls
> from being made, but this is harmless.
>
> Because unmap_grant_pages is now async, the grant handle will be sent to
> INVALID_GRANT_HANDLE too late to prevent multiple unmaps of the same
> handle. Instead, a separate bool array is allocated for this purpose.
> This wastes memory, but stuffing this information in padding bytes is
> too fragile. Furthermore, it is necessary to grab a reference to the
> map before making the asynchronous call, and release the reference when
> the call returns.
I think there is even more syncing needed:
- In the error path of gntdev_mmap() unmap_grant_pages() is being called and
it is assumed, map is available afterwards again. This should be rather easy
to avoid by adding a counter of active mappings to struct gntdev_grant_map
(number of pages not being unmapped yet). In case this counter is not zero
gntdev_mmap() should bail out early.
- gntdev_put_map() is calling unmap_grant_pages() in case the refcount has
dropped to zero. This call can set the refcount to 1 again, so there is
another delay needed before freeing map. I think unmap_grant_pages() should
return in case the count of mapped pages is zero (see above), thus avoiding
to increment the refcount of map if nothing is to be done. This would enable
gntdev_put_map() to just return after the call of unmap_grant_pages() in case
the refcount has been incremented again.
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
next prev parent reply other threads:[~2022-05-30 6:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-25 18:41 [PATCH v2] xen/gntdev: Avoid blocking in unmap_grant_pages() Demi Marie Obenour
2022-05-30 6:41 ` Juergen Gross [this message]
2022-05-30 17:50 ` Demi Marie Obenour
2022-06-02 9:54 ` Juergen Gross
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=00c0b10c-a35d-6729-5b4f-424febd9d5a3@suse.com \
--to=jgross@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=demi@invisiblethingslab.com \
--cc=jennifer.herbert@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marmarek@invisiblethingslab.com \
--cc=sstabellini@kernel.org \
--cc=stable@vger.kernel.org \
--cc=xen-devel@lists.xenproject.org \
/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