On Mon, Jul 22, 2024 at 02:49:12PM +0800, Yan Zhao wrote: > On Fri, Jul 19, 2024 at 10:13:33AM -0400, Peter Xu wrote: > > On Fri, Jul 19, 2024 at 10:28:09AM +0200, David Hildenbrand wrote: > > > On 19.07.24 01:18, Yan Zhao wrote: > > > > On Thu, Jul 18, 2024 at 10:03:01AM -0400, Peter Xu wrote: > > > > > On Thu, Jul 18, 2024 at 09:50:31AM +0800, Yan Zhao wrote: > > > > > > Ok. Then if we have two sets of pfns, then we can > > > > > > 1. Call remap_pfn_range() in mmap() for pfn set 1. > > > > > > > > > > I don't think this will work.. At least from the current implementation, > > > > > remap_pfn_range() will only reserve the memtype if the range covers the > > > > > whole vma. > > > > Hmm, by referring to pfn set 1 and pfn set 2, I mean that they're both > > > > covering the entire vma, but at different times. > > > > > > > > To make it more accurately: > > > > > > > > Consider this hypothetical scenario (not the same as what's implemented in > > > > vfio-pci, but seems plausible): > > > > > > > > Suppose we have a vma covering only one page, then > > > > (1) Initially, the vma is mapped to pfn1, with remap_pfn_range(). > > > > (2) Subsequently, unmap_single_vma() is invoked to unmap the entire VMA. > > > > (3) The driver then maps the entire vma to pfn2 in fault handler > > > > > > > > Given this context, my questions are: > > > > 1. How can we reserve the memory type for pfn2? Should we call > > > > track_pfn_remap() in mmap() in advance? > > > > 2. How do we untrack the memory type for pfn1 and pfn2, considering they > > > > belong to the same VMA but mutual exclusively and not concurrently? > > > > > > Do we really have to support such changing PFNs in a VMA? Are there existing > > > use cases that would rely on that? > > > > I share the same question with David. I don't think we support that, and I > > don't know whether we should, either. > > > > Such flexibility already will break with current PAT design. See: > Previously with remap_pfn_range() being able to be called in fault handlers, > this flexibility is doable. i.e. reserve in the fault handler and untrack > in unmap_single_vma(). AFAICT, remap_pfn_range() should never be allowed to be called in a fault handler.. So IMO it's not "it was allowed before", but we did it wrong from when we used it in fault path: remap_pfn_range() changes VMA flags since the 1st day, and that requires a writable lock, while fault paths only hold it read.. I think it's just that the per-vma lock was added a few years ago (then some lock attestations on vma lock v.s. vma flag changes), and until then we found this issue. -- Peter Xu
