From: David Woodhouse <dwmw2@infradead.org>
To: iommu@lists.linux-foundation.org, linux-mm@kvack.org
Cc: "Tang, CQ" <cq.tang@intel.com>
Subject: Re: [PATCH] iommu/vt-d: Fix mm refcounting to hold mm_count not mm_users
Date: Wed, 03 Feb 2016 12:52:55 +0000 [thread overview]
Message-ID: <1454503975.4788.188.camel@infradead.org> (raw)
In-Reply-To: <1452720905.88154.75.camel@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 2893 bytes --]
On Wed, 2016-01-13 at 21:35 +0000, David Woodhouse wrote:
> Holding mm_users works OK for graphics, which was the first user of SVM
> with VT-d. However, it works less well for other devices, where we actually
> do a mmap() from the file descriptor to which the SVM PASID state is tied.
>
> In this case on process exit we end up with a recursive reference count:
> - The MM remains alive until the file is closed and the driver's release()
> call ends up unbinding the PASID.
> - The VMA corresponding to the mmap() remains intact until the MM is
> destroyed.
> - Thus the file isn't closed, even when exit_files() runs, because the
> VMA is still holding a reference to it. And the MM remains alive…
>
> To address this issue, we *stop* holding mm_users while the PASID is bound.
> We already hold mm_count by virtue of the MMU notifier, and that can be
> made to be sufficient.
>
> It means that for a period during process exit, the fun part of mmput()
> has happened and exit_mmap() has been called so the MM is basically
> defunct. But the PGD still exists and the PASID is still bound to it.
>
> During this period, we have to be very careful — exit_mmap() doesn't use
> mm->mmap_sem because it doesn't expect anyone else to be touching the MM
> (quite reasonably, since mm_users is zero). So we also need to fix the
> fault handler to just report failure if mm_users is already zero, and to
> temporarily bump mm_users while handling any faults.
>
> Additionally, exit_mmap() calls mmu_notifier_release() *before* it tears
> down the page tables, which is too early for us to flush the IOTLB for
> this PASID. And __mmu_notifier_release() removes every notifier from the
> list, so when exit_mmap() finally *does* tear down the mappings and
> clear the page tables, we don't get notified. So we work around this by
> clearing the PASID table entry in our MMU notifier release() callback.
> That way, the hardware *can't* get any pages back from the page tables
> before they get cleared.
>
> Hardware designers have confirmed that the resulting 'PASID not present'
> faults should be handled just as gracefully as 'page not present' faults,
> the important criterion being that they don't perturb the operation for
> any *other* PASID in the system.
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
> Cc: stable@vger.kernel.org
OK, I've finally managed to test this on SKL hardware, having brought
the i915 SVM support up to date:
http://git.infradead.org/users/dwmw2/linux-svm.git/shortlog/refs/heads/i915-svm
I believe it's working — CQ can you confirm that you're still happy
with it, please? I'll send it to Linus if so.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]
prev parent reply other threads:[~2016-02-03 12:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-13 21:35 David Woodhouse
2016-02-03 12:52 ` David Woodhouse [this message]
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=1454503975.4788.188.camel@infradead.org \
--to=dwmw2@infradead.org \
--cc=cq.tang@intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-mm@kvack.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