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

[David Hildenbrand <david@redhat.com>]

On 22.09.25 16:13, Pedro Falcato wrote:
> 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.

Thanks, yeah that makes sense. Whenever we add a folio to the swapcache 
we mark it dirty, so it's guaranteed that whatever content it had (even 
if just zeroes) will be written out.

-- 
Cheers

David / dhildenb