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
