On Tue, Jul 07, 2026 at 04:46:13PM +0200, David Hildenbrand (Arm) wrote: > On 6/29/26 14:23, Lorenzo Stoakes wrote: > > Describe what vma_start_pgoff() and vma_last_pgoff() actually provide in > > detail. > > > > This is in order that we can differentiate this between functions that will > > be added in a subsequent patch which provide a different page offset. > > > > No functional change intended. > > > > Signed-off-by: Lorenzo Stoakes <[email protected]> > > --- > > include/linux/mm.h | 26 ++++++++++++++++++++++++++ > > 1 file changed, 26 insertions(+) > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index 059144435729..2f00c75e66bd 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -4278,11 +4278,37 @@ static inline unsigned long vma_pages(const struct > > vm_area_struct *vma) > > return (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; > > } > > > > +/** > > + * vma_start_pgoff() - Get the page offset of the start of @vma > > + * @vma: The VMA whose page offset is required. > > + * > > + * If the VMA is file-backed, this is the page offset into the file. > > + * > > + * If the VMA is anonymous, this is the virtual page offset of the start > > of the > > + * VMA - if unfaulted, then vma->vm_start >> PAGE_SHIFT, if faulted then > > the > > + * virtual page offset at the time of first fault. > > + * > > + * Note that if @vma is a MAP_PRIVATE file-backed mapping, then this > > returns the > > + * file offset. > > There is the ugly case of @vma being a MAP_PRIVATE PFNMAP mapping, where it > returns something different.
Yup, the pfn I will update doc to mention this abomination too. The virt pgoff stuff in the RFC fixes this also. > > (remap_pfn_range_prepare_vma() -> vma->vm_pgoff set to PFN) > > -- > Cheers, > > David Cheers, Lorenzo
