Re: [PATCH v3 07/15] mm/rmap: track whether the page VMA mapped pgoff is anonymous

On Mon, Aug 03, 2026 at 04:02:45PM +0200, David Hildenbrand (Arm) wrote:
> On 8/3/26 15:51, Lorenzo Stoakes (ARM) wrote:
> > On Mon, Aug 03, 2026 at 12:57:44PM +0200, David Hildenbrand (Arm) wrote:
> >>>  /*
> >>> - * Then at what user virtual address will none of the range be found in vma?
> >>> + * At what user virtual address will none of the range be found in vma?
> >>>   * Assumes that vma_address() already returned a good starting address.
> >>>   */
> >>>  static inline unsigned long vma_address_end(struct page_vma_mapped_walk *pvmw)
> >>>  {
> >>> -	struct vm_area_struct *vma = pvmw->vma;
> >>> -	pgoff_t pgoff;
> >>> +	const struct vm_area_struct *vma = pvmw->vma;
> >>> +	const pgoff_t pgoff = pvmw->pgoff;
> >>> +	pgoff_t pgoff_vma_start;
> >>>  	unsigned long address;
> >>> +	pgoff_t pgoff_end;
> >>>
> >>>  	/* Common case, plus ->pgoff is invalid for KSM */
> >>>  	if (pvmw->nr_pages == 1)
> >>>  		return pvmw->address + PAGE_SIZE;
> >>>
> >>> -	pgoff = pvmw->pgoff + pvmw->nr_pages;
> >>> +	pgoff_vma_start = vma_start_pgoff(vma);
> >>> +	pgoff_end = pgoff + pvmw->nr_pages;
> >>>  	address = vma->vm_start +
> >>> -		((pgoff - vma_start_pgoff(vma)) << PAGE_SHIFT);
> >>> +		((pgoff_end - pgoff_vma_start) << PAGE_SHIFT);
> >>>  	/* Check for address beyond vma (or wrapped through 0?) */
> >>>  	if (address < vma->vm_start || address > vma->vm_end)
> >>>  		address = vma->vm_end;
> >>
> >> Am I wrong or are all all changes here completely irrelevant for this patch?
> >>
> >> You mention
> >>
> >> "This is necessary in order to determine the correct VMA page
> >> offset in vma_address_end() when pvmw->nr_pages > 1."
> >>
> >> But I don't spot an effective change here.
> >
> > As per commit message:
> >
> > 	This is laying the groundwork for eventually using anonymous page offsets
> > 	as the index for all anonymous folios.
> >
> > 	No functional change intended.
> >
> > I cannot enable an effective change here, because if I did I'd break the kernel
> > and introduce a bisection hazard.
>
> You can just throw in a patch that cleans that up and avoids messing with confusing pgoff?

You mean do a separate patch for this change?

The existing code is already very confusing :) it becomes worse with the
anon stuff added, hence the change.

I will separate it out assuming this is what you mean?

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo