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

On Thu, Jul 30, 2026 at 02:39:27AM -0400, Gregory Price wrote:
> On Thu, Jul 30, 2026 at 12:58:22AM -0400, Gregory Price wrote:
> > 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
> >
>
> After re-reading the cover-letter again - my note here is wrong and
> my brain hurts more.
>
> ... determines the address of a folio's index within a VMA when
>   - the folio belongs to a MAP_PRIVATE file-backed VMA, but
>   - <The Folio> has been CoW'd
>   - thus <The CoW'd Folio> is <now marked> anonymous
>   - The original folio may or may not have been anonymous
>     (depending on whether it, itself, was a CoW copy)

Yeah :) this message is meant to be effectively a placeholder for 'there's a
good reason for doing this' :) I go to greater lengths to explain in the bits
that actually implement it.

>
> Lorenzo you are truly doing Darwin's work untangling all of this.

Thanks :)

This is really painful stuff and trying to get to scalable CoW the 'right way'
(i.e. several series and probably 3 figures of patches) is a slog, but once in
place will be worthwhile (and also save a bunch of memory :)

>
> ~Gregory