Re: [RFC PATCH v3 3/8] mm/gup: split follow_page_pte_commit() out of follow_page_pte()

On Wed, 2026-08-12 at 15:23 +0200, David Hildenbrand (Arm) wrote:
> On 8/12/26 15:02, Rik van Riel wrote:
> 
> > 
> > Looking at the differences between the pte and pmd
> > code, there is another big thing that stands out.
> > 
> > The pte code will call mark_folio_dirty() when
> > needed, but the pmd and pud code do not.
> 
> Yes, and my gut feeling is that the same helper should be also used
> in the other
> places. Maybe there is no real bug there, but the inconsistency is
> concerning.

Heh, now the filesystem people want sub-folio dirty
tracking, to reduce write amplification.

https://lore.kernel.org/all/[email protected]/

This makes me wonder that while your suggestion
makes sense for anonymous and tmpfs memory, we might
need something else for filesystem backed large
folios and get_user_pages?

Thinking about it some more, we are marking the 
folio dirty before (potentially long before) a write
is actually done.

Doesn't that give the flushing code time to clean
the page (by writing out content identical to what
is already on disk) before the actual dirtying of
the memory, through e.g. PTRACE_POKE is done?

Does the dirtying of folios and/or pages need to
be done when they are actually being written to,
and not at GUP time?

It looks like __access_remote_vm() already does
that dirtying, as do most of the other places
that use GUP with FOLL_WRITE.

A number of places use unpin_user_pages_dirty(_lock)
to get the pages marked dirty at unpin time, after
the data has been written into the pages.

However, there seem to be some places in the
kernel that are not marking pages dirty when
they write after GUP with FOLL_WRITE.

I suppose we need to fix those, given how
sometimes they can pin pages for a long time,
and do multiple writes over a long period of
time?

I'm combing through the tree now to find those
places.

This raises the question whether we want to
call mark_folio_dirty() at all from inside
GUP.

-- 
All Rights Reversed.