Re: [PATCH stable] mm/khugepaged: write all dirty file folios when collapsing

[David Hildenbrand (Arm)]

On 7/3/26 11:02, Lance Yang wrote:
> 
> On Fri, Jul 03, 2026 at 10:55:42AM +0200, David Hildenbrand (Arm) wrote:
>> On 7/2/26 18:54, Pedro Falcato wrote:
>>> As-is, khugepaged and writable-file opening exclude each other. A file
>>> cannot be open writeable and have THPs (because the filesystem is not aware
>>> of them). khugepaged will never collapse file pages for files that are
>>> opened writeable. On an open(O_RDWR/O_WRONLY), the page cache for that
>>> particular file is dropped. This is fine because nothing could've been
>>> dirtied.
>>>
>>> However, there is an edge-case: collapse_file() might not be able to
>>> coexist with concurrent writers, but it can coexist with dirty folios
>>> (from previous writers). Therefore, the following can happen:
>>>
>>> open(file, O_RDWR)
>>> write(file)
>>> close(file)
>>
>> Okay, folios are dirty.
>>
>>> madvise(file_mapping, MADV_COLLAPSE, some non-dirty range)
>>
>> collapse_file() has
>>
>> 	if (!is_shmem && (folio_test_dirty(folio) ||
>> 			  folio_test_writeback(folio))) {
>> 		...
>> 		result = SCAN_PAGE_DIRTY_OR_WRITEBACK;
>> 		goto out_unlock;
>> 	}
>>
>> Making us abort collapse.
>>
>> What am I missing?
> 
> Hmm ... dirty folios can be outside the range being collapsed ...
> 
> For example:
> 
>   write/dirty:      [6M, 8M)
>   MADV_COLLAPSE:    [0M, 2M)
> 
> collapse_file() only checks the folios in the collapse range, so the
> dirty/writeback check passes for [0M, 2M). But after that, for the old
> READ_ONLY_THP_FOR_FS case, nr_thps gets bumped for the mapping.

Ahh, so it's unrelated folios, thanks for clarifying that.

("some non-dirty range" documents that)

All makes sense to me, thanks!

-- 
Cheers,

David