Re: [PATCH v3 03/15] mm: abstract vma_address() and introduce vma_anon_address()

On Wed, Jul 29, 2026 at 05:48:38PM +0100, Lorenzo Stoakes (ARM) wrote:
> 
> This will be necessary for determining the address of a folio's index
> within a VMA when the folio belongs to a MAP_PRIVATE file-backed VMA but
> has been CoW'd, and thus is anonymous, once the anonymous VMA page offset
> field is used for the reverse mapping.
> 

This is a doozy of a sentence... 

... determines the address of a folio's index within a VMA when
  - the folio belongs to a MAP_PRIVATE file-backed VMA, but
  - <The VMA> has been cow'd
  - thus <The CoW'd VMA> is anonymous (as well)
  - The original VMA may or may not also be marked anonymous?
    (just clarifying, could be original mapper or a COW that COWs)

Ow, my brain.  One question below

> +static inline unsigned long vma_address(const struct vm_area_struct *vma,
> +		pgoff_t pgoff, unsigned long nr_pages)
> +{
> +	return __vma_address(vma, pgoff, vma_start_pgoff(vma), nr_pages);
> +}
> +
... snip ...
> +static inline unsigned long vma_anon_address(const struct vm_area_struct *vma,
> +		pgoff_t pgoff_anon, unsigned long nr_pages)
> +{
> +	VM_WARN_ON_ONCE(!vma_is_anonymous(vma) && vma_test(vma, VMA_SHARED_BIT));
> +
> +	return __vma_address(vma, pgoff_anon, vma_start_anon_pgoff(vma), nr_pages);
> +}
> +

Why make the caller have to know anon vs not-anon if you can determine
from the vma bits which vma_start_pgoff variant to use?

(I suppose this is probably the entire point of the series, just trying
to get some clarity on the increased API surface).

~Gregory