tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

mm: propagate VM_SOFTDIRTY on merge

Patch series "make VM_SOFTDIRTY a sticky VMA flag", v2.

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.

Now we have the concept of making VMA flags 'sticky', that is that they
both don't prevent merge and, importantly, are propagated to merged VMAs,
this seems a sensible alternative to the existing special-casing of
VM_SOFTDIRTY.

We additionally add a self-test that demonstrates that this logic behaves
as expected.


This patch (of 2):

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.

This is because currently we simply ignore VM_SOFTDIRTY for the purposes
of merge, so one VMA may possess the flag and another not, and whichever
happens to be the target VMA will be the one upon which the merge is
performed which may or may not have VM_SOFTDIRTY set.

Now we have the concept of 'sticky' VMA flags, let's make VM_SOFTDIRTY one
which solves this issue.

Additionally update VMA userland tests to propagate changes.

[akpm@linux-foundation.org: update comments, per Lorenzo]
Link: https://lkml.kernel.org/r/0019e0b8-ee1e-4359-b5ee-94225cbe5588@lucifer.local
Link: https://lkml.kernel.org/r/cover.1763399675.git.lorenzo.stoakes@oracle.com
Link: https://lkml.kernel.org/r/955478b5170715c895d1ef3b7f68e0cd77f76868.1763399675.git.lorenzo.stoakes@oracle.com
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Suggested-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: David Hildenbrand (Red Hat) <david@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
Acked-by: Andrey Vagin <avagin@gmail.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Jann Horn <jannh@google.com>
Cc: Liam Howlett <liam.howlett@oracle.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

authored by

Lorenzo Stoakes and committed by
Andrew Morton 6707915e 6e57c1ce

+13 -20
+7 -8
include/linux/mm.h
··· 532 532 * possesses it but the other does not, the merged VMA should nonetheless have 533 533 * applied to it: 534 534 * 535 + * VM_SOFTDIRTY - if a VMA is marked soft-dirty, that is has not had its 536 + * references cleared via /proc/$pid/clear_refs, any merged VMA 537 + * should be considered soft-dirty also as it operates at a VMA 538 + * granularity. 539 + * 535 540 * VM_MAYBE_GUARD - If a VMA may have guard regions in place it implies that 536 541 * mapped page tables may contain metadata not described by the 537 542 * VMA and thus any merged VMA may also contain this metadata, 538 543 * and thus we must make this flag sticky. 539 544 */ 540 - #define VM_STICKY VM_MAYBE_GUARD 545 + #define VM_STICKY (VM_SOFTDIRTY | VM_MAYBE_GUARD) 541 546 542 547 /* 543 548 * VMA flags we ignore for the purposes of merge, i.e. one VMA possessing one 544 549 * of these flags and the other not does not preclude a merge. 545 550 * 546 - * VM_SOFTDIRTY - Should not prevent from VMA merging, if we match the flags but 547 - * dirty bit -- the caller should mark merged VMA as dirty. If 548 - * dirty bit won't be excluded from comparison, we increase 549 - * pressure on the memory system forcing the kernel to generate 550 - * new VMAs when old one could be extended instead. 551 - * 552 551 * VM_STICKY - When merging VMAs, VMA flags must match, unless they are 553 552 * 'sticky'. If any sticky flags exist in either VMA, we simply 554 553 * set all of them on the merged VMA. 555 554 */ 556 - #define VM_IGNORE_MERGE (VM_SOFTDIRTY | VM_STICKY) 555 + #define VM_IGNORE_MERGE VM_STICKY 557 556 558 557 /* 559 558 * Flags which should result in page tables being copied on fork. These are
+6 -12
tools/testing/vma/vma_internal.h
··· 122 122 * possesses it but the other does not, the merged VMA should nonetheless have 123 123 * applied to it: 124 124 * 125 - * VM_MAYBE_GUARD - If a VMA may have guard regions in place it implies that 126 - * mapped page tables may contain metadata not described by the 127 - * VMA and thus any merged VMA may also contain this metadata, 128 - * and thus we must make this flag sticky. 125 + * VM_SOFTDIRTY - if a VMA is marked soft-dirty, that is has not had its 126 + * references cleared via /proc/$pid/clear_refs, any merged VMA 127 + * should be considered soft-dirty also as it operates at a VMA 128 + * granularity. 129 129 */ 130 - #define VM_STICKY VM_MAYBE_GUARD 130 + #define VM_STICKY (VM_SOFTDIRTY | VM_MAYBE_GUARD) 131 131 132 132 /* 133 133 * VMA flags we ignore for the purposes of merge, i.e. one VMA possessing one 134 134 * of these flags and the other not does not preclude a merge. 135 135 * 136 - * VM_SOFTDIRTY - Should not prevent from VMA merging, if we match the flags but 137 - * dirty bit -- the caller should mark merged VMA as dirty. If 138 - * dirty bit won't be excluded from comparison, we increase 139 - * pressure on the memory system forcing the kernel to generate 140 - * new VMAs when old one could be extended instead. 141 - * 142 136 * VM_STICKY - When merging VMAs, VMA flags must match, unless they are 143 137 * 'sticky'. If any sticky flags exist in either VMA, we simply 144 138 * set all of them on the merged VMA. 145 139 */ 146 - #define VM_IGNORE_MERGE (VM_SOFTDIRTY | VM_STICKY) 140 + #define VM_IGNORE_MERGE VM_STICKY 147 141 148 142 /* 149 143 * Flags which should result in page tables being copied on fork. These are