linux-kernel - Re: [PATCH 0/2] make VM_SOFTDIRTY a sticky VMA flag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1c20ec44-0775-47e0-aabb-e1cf1f38ce94@lucifer.local>
Date: Mon, 17 Nov 2025 11:32:55 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrei Vagin <avagin@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        David Hildenbrand <david@...nel.org>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
        Jann Horn <jannh@...gle.com>, Pedro Falcato <pfalcato@...e.de>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org, criu@...ts.linux.dev
Subject: Re: [PATCH 0/2] make VM_SOFTDIRTY a sticky VMA flag

On Sun, Nov 16, 2025 at 04:53:36PM -0800, Andrei Vagin wrote:
> On Fri, Nov 14, 2025 at 9:59 AM Lorenzo Stoakes
> <lorenzo.stoakes@...cle.com> wrote:
> >
> > Currently we set VM_SOFTDIRTY when a new mapping is set up (whether by
> > establishing a new VMA, or via merge) as implemented in __mmap_complete()
> > and do_brk_flags().
> >
> > However, when performing a merge of existing mappings such as when
> > performing mprotect(), we may lose the VM_SOFTDIRTY flag.
>
> Losing VM_SOFTDIRTY is definitely a bug, thank you for fixing it.
>
> A separate concern is whether merging two VMAs should be permitted when
> one has the VM_SOFTDIRTY flag set and another does not. I think the
> merging operation should be disallowed.The  issue is that

This patch doesn't change anything in terms of merging, it only _correctly_
marks VMAs as soft-dirty where certain, very specific, circumstances might
result in a merged VMA being incorrectly indicated to not be soft-dirty
when it in fact contains pages which are.

Since VMA fragmentation is an issue that impacts non-softydirty users, I'm
afraid we cannot split on this parameter.

It'd also be a user-visible change that could cause breaking issues
(mremap() for instances in _most_ cases requires that it operates on a
single VMA).

So this isn't possible.

> PAGE_IS_SOFT_DIRTY will be reported for every page in the resulting VMA.
> Consider a scenario where a large VMA has only a small number of pages
> marked SOFT_DIRTY. If we merge it with a smaller VMA that does have
> VM_SOFTDIRTY, all pages in the originally large VMA will subsequently be
> reported as SOFT_DIRTY. As a result, CRIU will needlessly dump all of
> these pages again, even though the vast majority of them were unchanged
> since the prior checkpoint iteration.

I think there's some confusion about what is possible here.

Currently if you don't invoke /proc/$pid/clear_refs, all VMAs will have
soft-dirty set until you do.

So this is a situation that _already exists_.

And intentionally so - we default all VMAs to soft-dirty so users can
detect new mappings in order not to perceive e.g. mmap()'ing over an
existing range as as being no change.

OK so what if you clear references? Considering:

1. Map large VMA
2. Clear references
3. Dirty several pages (VM_SOFTDIRTY clear)
4. Map new VMA immediately _after_ it (VM_SOFTDIRTY set)
5. Merge - Before this patch: VM_SOFTDIRTY bit cleared on merge BUT SET
   AGAIN due to it being an mmap() invocation. After this patch:
   VM_SOFTDIRTY bit retained on merge but also set again due to it being an
   mmap() invocation.

So this kind of merge has no change in behaviour.

And again, it's correct - the user needs to be able to identify what's
changed.

This change fixes this behaviour to be consistent for other types of merge,
when previously it was not.

In the past, you'd get soft-dirty set/not set _depending on the type of
merge_. So if the target VMA had the flag set, you'd have it marked
soft-dirty, otherwise not.

Since it's unacceptabale to fragment VMAs on the basis of soft-dirty, we're
_only_ improving correctness here, and this patch is a net good no matter
what.

>
> Thanks,
> Andrei
>
> >
> >
> > Lorenzo Stoakes (2):
> >   mm: propagate VM_SOFTDIRTY on merge
> >   testing/selftests/mm: add soft-dirty merge self-test
> >
> >  include/linux/mm.h                      | 23 ++++++-----
> >  tools/testing/selftests/mm/soft-dirty.c | 51 ++++++++++++++++++++++++-
> >  tools/testing/vma/vma_internal.h        | 23 ++++++-----
> >  3 files changed, 72 insertions(+), 25 deletions(-)
> >
> > --
> > 2.51.0
> >

Cheers, Lorenzo