Re: [PATCH v4 01/20] mm/vma: introduce VMA anon page offset field and add helpers

On Mon, Aug 10, 2026 at 1:36 AM Lorenzo Stoakes (ARM) <[email protected]> wrote:
>
> On Sat, Aug 08, 2026 at 05:51:10PM -0700, Suren Baghdasaryan wrote:
> > On Thu, Aug 6, 2026 at 1:22 PM Lorenzo Stoakes (ARM) <[email protected]> wrote:
> > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > index 87feaa5a2b78..df78847f5f07 100644
> > > --- a/include/linux/mm.h
> > > +++ b/include/linux/mm.h
> > > @@ -4393,6 +4393,65 @@ static inline pgoff_t vma_last_pgoff(const struct vm_area_struct *vma)
> > >         return vma_end_pgoff(vma) - 1;
> > >  }
> > >
> > > +/**
> > > + * vma_start_anon_pgoff() - Get the anonymous page offset of the start of @vma
> > > + * @vma: The VMA whose anonymous page offset is required.
> > > + *
> > > + * If unfaulted, then this is vma->vm_start >> PAGE_SHIFT, if faulted then the
> > > + * anonymous page offset at the time of first fault.
> > > + *
> > > + * If the VMA is anonymous, this returns the same value as vma_start_pgoff().
> > > + *
> > > + * This value is used for tracking MAP_PRIVATE file-backed mappings by their
> > > + * anonymous page offset.
> >
> > I assume this function should not be used with shared file-backed
> > mappings, right? If so, maybe add a comment like the one you have for
> > linear_anon_page_index(): "It is not valid to call this function for
> > shared file-backed mappings."?
>
> No that's not the case, it is valid to access this for any VMA though it's only
> meaningful for MAP_PRIVATE and anonymous VMAs (though in the latter case pgoff
> == anon pgoff).
>
> The code keeps the anon pgoff values consistent even for shared mappings because
> - hey - we have the field anyway and it's easiest and safest to just keep it the
> same.
>
> One alternative would be to have code that checks the flags and zeroes the field
> otherwise , but then you have problems like - early on initialisation now
> there's an ordering requirement which can easily go wrong.
>
> Another alternative is to just leave it stale, but then that seems objectively
> worse and again requires branching code on update and set.
>
> All-in-all it's easier to keep this working the same for any type of mapping,
> it's just useless to do anything with the anon pgoff for a shared mapping :)

Makes sense. Thanks for the explanation!

>
> --
> Cheers, Lorenzo