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
