[PATCH 13/46] mm/huge_memory: fix truncate racing with PMD zapping
David Hildenbrand (Arm)
david at kernel.org
Wed Oct 28 01:16:31 PDT 2026
On 10/28/26 03:54, Zi Yan wrote:
> On Mon Oct 26, 2026 at 7:17 PM EDT, David Hildenbrand (Arm) wrote:
>> From: Chris Mason <mason at kernel.org>
>>
>> zap_huge_pmd_folio() removes the rmap before calling folio_mark_dirty().
>> If this was the last mapping, truncation can skip unmapping the folio
>> and proceed without waiting for the PMD lock, racing with dirtying.
>>
>> ifs_set_range_dirty() can oops if MADV_DONTNEED races with
>> ftruncate() on XFS, when we get the folio set dirty after it was found
>> to not be mapped anymore.
>>
>> Move folio_mark_dirty() and folio_mark_accessed() before rmap removal,
>> matching the PTE zap path. This keeps the folio mapped while updating
>> its state, so truncation must wait for the page table lock.
>>
>> Fix generated by an LLM and sent by Chris Mason in private.
>>
>> Fixes: fe6cf984939d ("mm/huge_memory: transfer the pmd dirty bit to the folio on zap")
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Chris Mason <mason at kernel.org>
>> [ david: simplify comment and description ]
>> Signed-off-by: David Hildenbrand (Arm) <david at kernel.org>
>> ---
>> mm/huge_memory.c | 14 ++++++++------
>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>
>
> It seems to me that moving the rmap removal code after folio_mark_*()
> matches zap_present_folio_ptes() closer.
Yes, can do that! Thanks!
--
Cheers,
David
More information about the kexec
mailing list