Re: [RFC] mm: MAP_POPULATE on writable anonymous mappings marks pte dirty is necessarily?

[Pedro Falcato <pfalcato@suse.de>]

On Mon, Sep 22, 2025 at 02:46:44PM +0200, David Hildenbrand wrote:
> On 22.09.25 11:37, Pedro Falcato wrote:
snip
> > 
> > > What happens on architectures where the HW doesn't support setting the dirty
> > > bit is that performing a pte_mkwrite() checks whether the pte is dirty. If
> > > it's not dirty the HW write bit will not be set and instead the next
> > > pte_mkdirty() will set the actual HW write bit.
> > > 
> > > See pte_mkwrite() handling in arch/sparc/include/asm/pgtable_64.h or
> > > arch/s390/include/asm/pgtable.h
> > > 
> > > Of course, setting the dirty bit either way on later access comes with a
> > > price.
> > 
> > Ah, yes, the details were a little fuzzy in my head, thanks.
> > I'm trying to swap in (ha!) the details again. We still proactively mark anon
> > folios dirty anyway for $reasons, so optimizing it might be difficult? Not sure
> > if it is _worth_ optimizing for anyway.
> 
> I remembered the same thing (proactively mark anon folios dirty) but I
> didn't easily spot it in the code. Did you spot it?
> 
> I only found the folio_mark_dirty() calls when unmapping anon pages and we
> stumble over a dirty pte.
> 

In shrink_folio_list():
		if (folio_test_anon(folio) && folio_test_swapbacked(folio)) {
			if (!folio_test_swapcache(folio)) {
			/* ... */
				/*
				 * Normally the folio will be dirtied in unmap because its
				 * pte should be dirty. A special case is MADV_FREE page. The
				 * page's pte could have dirty bit cleared but the folio's
				 * SwapBacked flag is still set because clearing the dirty bit
				 * and SwapBacked flag has no lock protected. For such folio,
				 * unmap will not set dirty bit for it, so folio reclaim will
				 * not write the folio out. This can cause data corruption when
				 * the folio is swapped in later. Always setting the dirty flag
				 * for the folio solves the problem.
				*/
				folio_mark_dirty(folio);
			}
		}

So we assume the folio is dirty due to races with MADV_FREE. Seems like a
somewhat heavy handed solution, but I guess it works nicely for 99.9% of cases.

-- 
Pedro