From: Christoph Hellwig <hch@infradead.org>
To: Ralph Campbell <rcampbell@nvidia.com>
Cc: Jerome Glisse <jglisse@redhat.com>,
John Hubbard <jhubbard@nvidia.com>,
Felix.Kuehling@amd.com, Jason Gunthorpe <jgg@mellanox.com>,
linux-rdma@vger.kernel.org, linux-mm@kvack.org,
Andrea Arcangeli <aarcange@redhat.com>,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Subject: Re: [RFC] mm/hmm: pass mmu_notifier_range to sync_cpu_device_pagetables
Date: Sat, 8 Jun 2019 02:10:08 -0700 [thread overview]
Message-ID: <20190608091008.GC32185@infradead.org> (raw)
In-Reply-To: <20190608001452.7922-1-rcampbell@nvidia.com>
On Fri, Jun 07, 2019 at 05:14:52PM -0700, Ralph Campbell wrote:
> HMM defines its own struct hmm_update which is passed to the
> sync_cpu_device_pagetables() callback function. This is
> sufficient when the only action is to invalidate. However,
> a device may want to know the reason for the invalidation and
> be able to see the new permissions on a range, update device access
> rights or range statistics. Since sync_cpu_device_pagetables()
> can be called from try_to_unmap(), the mmap_sem may not be held
> and find_vma() is not safe to be called.
> Pass the struct mmu_notifier_range to sync_cpu_device_pagetables()
> to allow the full invalidation information to be used.
>
> Signed-off-by: Ralph Campbell <rcampbell@nvidia.com>
> ---
>
> I'm sending this out now since we are updating many of the HMM APIs
> and I think it will be useful.
This is the right thing to do. But the really right thing is to just
kill the hmm_mirror API entirely and move to mmu_notifiers. At least
for noveau this already is way simpler, although right now it defeats
Jasons patch to avoid allocating the struct hmm in the fault path.
But as said before that can be avoided by just killing struct hmm,
which for many reasons is the right thing to do anyway.
I've got a series here, which is a bit broken (epecially the last
patch can't work as-is), but should explain where I'm trying to head:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/hmm-mirror-simplification
next prev parent reply other threads:[~2019-06-08 9:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-08 0:14 Ralph Campbell
2019-06-08 9:10 ` Christoph Hellwig [this message]
2019-06-08 11:41 ` Jason Gunthorpe
2019-06-10 0:16 ` John Hubbard
2019-06-08 11:50 ` Jason Gunthorpe
2019-06-09 19:46 ` Ira Weiny
2019-07-02 19:53 ` Jason Gunthorpe
2019-07-02 20:11 ` Ralph Campbell
2019-07-02 22:49 ` Christoph Hellwig
2019-07-02 22:59 ` Jason Gunthorpe
2019-07-03 0:03 ` Christoph Hellwig
2019-07-03 2:27 ` Kuehling, Felix
2019-07-03 15:08 ` Jason Gunthorpe
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=20190608091008.GC32185@infradead.org \
--to=hch@infradead.org \
--cc=Felix.Kuehling@amd.com \
--cc=aarcange@redhat.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jgg@mellanox.com \
--cc=jglisse@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=rcampbell@nvidia.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