diff options
| author | Lorenzo Stoakes <lorenzo.stoakes@oracle.com> | 2025-10-13 19:58:36 +0300 |
|---|---|---|
| committer | Andrew Morton <akpm@linux-foundation.org> | 2025-10-22 01:46:17 +0300 |
| commit | 0e59f47c15cec4cd88c51c5cda749607b719c82b (patch) | |
| tree | a08d74cb6149c2c32ebe85ce5232772f24269004 /tools/docs/lib/parse_data_structs.py | |
| parent | 841a8bfcbad94bb1ba60f59ce34f75259074ae0d (diff) | |
| download | linux-0e59f47c15cec4cd88c51c5cda749607b719c82b.tar.xz | |
mm/mremap: correctly account old mapping after MREMAP_DONTUNMAP remap
Commit b714ccb02a76 ("mm/mremap: complete refactor of move_vma()")
mistakenly introduced a new behaviour - clearing the VM_ACCOUNT flag of
the old mapping when a mapping is mremap()'d with the MREMAP_DONTUNMAP
flag set.
While we always clear the VM_LOCKED and VM_LOCKONFAULT flags for the old
mapping (the page tables have been moved, so there is no data that could
possibly be locked in memory), there is no reason to touch any other VMA
flags.
This is because after the move the old mapping is in a state as if it were
freshly mapped. This implies that the attributes of the mapping ought to
remain the same, including whether or not the mapping is accounted.
Link: https://lkml.kernel.org/r/20251013165836.273113-1-lorenzo.stoakes@oracle.com
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Fixes: b714ccb02a76 ("mm/mremap: complete refactor of move_vma()")
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
Cc: Jann Horn <jannh@google.com>
Cc: Liam Howlett <liam.howlett@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Diffstat (limited to 'tools/docs/lib/parse_data_structs.py')
0 files changed, 0 insertions, 0 deletions