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

[John Hubbard <jhubbard@nvidia.com>]

On 8/21/26 10:38 AM, Rik van Riel wrote:
> On Wed, 2026-08-12 at 15:23 +0200, David Hildenbrand (Arm) wrote:
>> On 8/12/26 15:02, Rik van Riel wrote:
...
> 
> 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.
> 

Hi Rik,

You have delved too deep, and now uncovered something that's been
a problem for the whole time. :)

Specifically, "no, GUP should not be setting folios nor pages
dirty", because that generally needs to be done as part of a filesystem
coordinated set of steps. If the page is dirty, and the filesystem
didn't expect it to be, that leads to problems.

This is part of the big, remaining set of required fixes, that
launched the creation of pin_user_pages*() and related. Connecting
up the filesystems properly is yet to be done. And until then, this
is a real defect.

thanks,
-- 
John Hubbard