Re: [PATCH v2] mm: fix VM_SOFTDIRTY propagation on VMA merge

Ahmed Elaidy
2026-05-04T19:54:45Z

[-- Attachment #1: Type: text/plain, Size: 3061 bytes --]

Hi Andrei,

Thanks for the review.

> Should we fix vma_merge_new_range too?

Yes, vma_merge_new_range() exhibited the exact same logic gap where
vma_expand() leaves the merged VMA without VM_SOFTDIRTY if the target
sequence didn't have it natively. I have added the exact same fix to
vma_merge_new_range() in v3.

> How are you testing this patch?

Testing was done using the CRIU ZDTM transition test suite
(soft-dirty-merged-vmas.c) on virtme-ng. The test enforces an unprivileged
namespace testing environment (ZDTM_ROOTLESS=1) where it tracks
VM_SOFTDIRTY across merged VMAs. The unpatched 6.18 kernel fails this
incremental tracking natively, but correctly propagates the bit with this
fix applied.

I've addressed the formatting suggestions and added the Fixes tag to point
to the 2014 commit (34228d473efe). I have just sent the v3 patch to the
list.

Best regards,
Ahmed

On Mon, May 4, 2026 at 7:42 PM Andrei Vagin <avagin@gmail.com> wrote:

>
>
> On Fri, Apr 24, 2026 at 3:11 PM Ahmed Elaidy <elaidya225@gmail.com> wrote:
>
>> During VMA merging, such as through mprotect(), VM_SOFTDIRTY flags could
>> be
>> lost. This breaks tools relying on soft-dirty tracking, such as CRIU
>> incremental dump/restore.
>>
>> Upstream resolved this using a broader VM_STICKY infrastructure (commit
>> bf14d4a05387 "mm: propagate VM_SOFTDIRTY on merge"). To minimize churn and
>> risk in the stable 6.18.y tree, this patch skips backporting the entire
>> VM_STICKY series (9 patches). Instead, it introduces a minimal standalone
>> fix.
>>
>> VM_SOFTDIRTY is intentionally excluded from normal flag comparison to
>> allow
>> merging in mprotect. This patch ensures the resulting merged VMA retains
>> the VM_SOFTDIRTY flag if either of the original VMAs had it.
>>
>> Suggested-by: Andrei Vagin <avagin@gmail.com>
>> Cc: stable@vger.kernel.org
>
>
> It probably should be: Cc: stable@vger.kernel.org # 6.18.x and
> the prefix in the subject can be [PATCH 6.18.y]..
>
> Please add The Fixes tag to the commit that introduced the issue.
>
>
>> Cc: lorenzo.stoakes@oracle.com
>> Signed-off-by: Ahmed Khalid Elaidy <elaidya225@gmail.com>
>> ---
>> mm/vma.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/mm/vma.c b/mm/vma.c
>> index 5815ae9e5770..03728d855684 100644
>> --- a/mm/vma.c
>> +++ b/mm/vma.c
>> @@ -978,6 +978,14 @@ static __must_check struct vm_area_struct
>> *vma_merge_existing_range(
>> if (err || commit_merge(vmg))
>> goto abort;
>>
>> + /*
>> + * VM_SOFTDIRTY is excluded from normal flag comparison to allow
>> + * merging in mprotect, but we have to ensure the result is
>> correctly
>> + * marked with it if either side had it.
>> + */
>> + if ((vmg->target->vm_flags ^ vmg->vm_flags) & VM_SOFTDIRTY)
>> + vm_flags_set(vmg->target, VM_SOFTDIRTY);
>>
>
> Should we fix vma_merge_new_range too?
>
> How are you testing this patch?
>
> Thanks,
> Andrei
>

[-- Attachment #2: Type: text/html, Size: 4344 bytes --]