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

"David Hildenbrand (Arm)" <[email protected]> Mon, 3 Aug 2026 16:02:45 +0200
Newsgroups org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kvack.linux-mm
Message-ID <[email protected]>
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?

-- 
Cheers,

David