From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Andrew Jones <ajones@ventanamicro.com>,
Yan Zhao <yan.y.zhao@intel.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
kevin.tian@intel.com, yishaih@nvidia.com,
shameerali.kolothum.thodi@huawei.com,
Peter Xu <peterx@redhat.com>
Subject: Re: [PATCH] vfio/pci: take mmap write lock for io_remap_pfn_range
Date: Wed, 22 May 2024 15:30:46 -0300 [thread overview]
Message-ID: <20240522183046.GG20229@nvidia.com> (raw)
In-Reply-To: <20240522115006.7746f8c8.alex.williamson@redhat.com>
On Wed, May 22, 2024 at 11:50:06AM -0600, Alex Williamson wrote:
> I'm not sure if there are any outstanding blockers on Peter's side, but
> this seems like a good route from the vfio side. If we're seeing this
> now without lockdep, we might need to bite the bullet and take the hit
> with vmf_insert_pfn() while the pmd/pud path learn about pfnmaps.
There is another alternative...
Ideally we wouldn't use the fault handler.
Instead when the MMIO becomes available again we'd iterate over all
the VMA's and do remap_pfn_range(). When the MMIO becomes unavailable
we do unmap_mapping_range() and remove it. This whole thing is
synchronous and the fault handler should simply trigger SIGBUS if
userspace races things.
unmap_mapping_range() is easy, but the remap side doesn't have a
helper today..
Something grotesque like this perhaps?
while (1) {
struct mm_struct *cur_mm = NULL;
i_mmap_lock_read(mapping);
vma_interval_tree_foreach(vma, mapping->i_mmap, 0, ULONG_MAX) {
if (vma_populated(vma))
continue;
cur_mm = vm->mm_struct;
mmgrab(cur_mm);
}
i_mmap_unlock_read(mapping);
if (!cur_mm)
return;
mmap_write_lock(cur_mm);
i_mmap_lock_read(mapping);
vma_interval_tree_foreach(vma, mapping->i_mmap, 0, ULONG_MAX) {
if (vma->mm_struct == mm)
vfio_remap_vma(vma);
}
i_mmap_unlock_read(mapping);
mmap_write_unlock(cur_mm);
mmdrop(cur_mm);
}
I'm pretty sure we need to hold the mmap_write lock to do the
remap_pfn..
vma_populated() would have to do a RCU read of the page table to check
if the page 0 is present.
Also there is a race in mmap if you call remap_pfn_range() from the
mmap fops and also use unmap_mapping_range(). mmap_region() does
call_mmap() before it does vma_link_file() which gives a window where
the VMA is populated but invisible to unmap_mapping_range(). We'd need
to add another fop to call after vma_link_file() to populate the mmap
or rely exclusively on the fault handler to populate.
Jason
next prev parent reply other threads:[~2024-05-22 18:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-08 12:58 [PATCH] vfio/pci: take mmap write lock for io_remap_pfn_range Yan Zhao
2023-05-08 16:48 ` Jason Gunthorpe
2023-05-08 20:57 ` Alex Williamson
2023-05-10 20:41 ` Jason Gunthorpe
2023-05-11 6:56 ` Yan Zhao
2023-05-11 7:38 ` Cédric Le Goater
2023-05-11 7:32 ` Cédric Le Goater
2023-05-11 16:07 ` Alex Williamson
2023-05-11 17:47 ` Jason Gunthorpe
2023-05-12 8:02 ` Yan Zhao
2024-05-22 16:56 ` Andrew Jones
2024-05-22 17:50 ` Alex Williamson
2024-05-22 18:30 ` Jason Gunthorpe [this message]
2024-05-22 19:43 ` Alex Williamson
2024-05-22 21:21 ` Peter Xu
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=20240522183046.GG20229@nvidia.com \
--to=jgg@nvidia.com \
--cc=ajones@ventanamicro.com \
--cc=alex.williamson@redhat.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterx@redhat.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=yan.y.zhao@intel.com \
--cc=yishaih@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