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
