On Mon, Sep 08, 2025 at 12:10:39PM +0100, Lorenzo Stoakes wrote: > remap_pfn_range_prepare() will set the cow vma->vm_pgoff if necessary, so > it must be supplied with a correct PFN to do so. If the caller must hold > locks to be able to do this, those locks should be held across the > operation, and mmap_abort() should be provided to revoke the lock should an > error arise. It seems very strange to me that callers have to provide locks. Today once mmap is called the vma priv should be allocated and access to the PFN is allowed - access doesn't stop until the priv is destroyed. So whatever refcounting the driver must do to protect PFN must already be in place and driven by the vma priv. When split I'd expect the same thing the prepare should obtain the vma priv and that locks the pfn. On complete the already affiliated PFN is mapped to PTEs. Why would any driver need a lock held to complete? Arguably we should store the remap pfn in the desc and just make complete a fully generic helper that fills the PTEs from the prepared desc. Jason
