[PATCH] mm/mremap: correctly account old mapping after MREMAP_DONTUNMAP remap

[PATCH] mm/mremap: correctly account old mapping after MREMAP_DONTUNMAP remap

[Lorenzo Stoakes]

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 memor), 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.

Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Fixes: b714ccb02a76 ("mm/mremap: complete refactor of move_vma()")
Cc: stable@kernel.org
---
 mm/mremap.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/mm/mremap.c b/mm/mremap.c
index 35de0a7b910e..bd7314898ec5 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -1237,10 +1237,10 @@ static int copy_vma_and_data(struct vma_remap_struct *vrm,
 }

 /*
- * Perform final tasks for MADV_DONTUNMAP operation, clearing mlock() and
- * account flags on remaining VMA by convention (it cannot be mlock()'d any
- * longer, as pages in range are no longer mapped), and removing anon_vma_chain
- * links from it (if the entire VMA was copied over).
+ * Perform final tasks for MADV_DONTUNMAP operation, clearing mlock() flag on
+ * remaining VMA by convention (it cannot be mlock()'d any longer, as pages in
+ * range are no longer mapped), and removing anon_vma_chain links from it if the
+ * entire VMA was copied over.
  */
 static void dontunmap_complete(struct vma_remap_struct *vrm,
 			       struct vm_area_struct *new_vma)
@@ -1250,11 +1250,8 @@ static void dontunmap_complete(struct vma_remap_struct *vrm,
 	unsigned long old_start = vrm->vma->vm_start;
 	unsigned long old_end = vrm->vma->vm_end;

-	/*
-	 * We always clear VM_LOCKED[ONFAULT] | VM_ACCOUNT on the old
-	 * vma.
-	 */
-	vm_flags_clear(vrm->vma, VM_LOCKED_MASK | VM_ACCOUNT);
+	/* We always clear VM_LOCKED[ONFAULT] on the old VMA. */
+	vm_flags_clear(vrm->vma, VM_LOCKED_MASK);

 	/*
 	 * anon_vma links of the old vma is no longer needed after its page
--
2.51.0

Re: [PATCH] mm/mremap: correctly account old mapping after MREMAP_DONTUNMAP remap

[Pedro Falcato]

On Mon, Oct 13, 2025 at 05:58:36PM +0100, Lorenzo Stoakes wrote:
> 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 memor), there is no reason to touch any other VMA
                        memory
> 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.
> 
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

Reviewed-by: Pedro Falcato <pfalcato@suse.de>

Looks good, thanks! Should we add a test for it?

-- 
Pedro

Re: [PATCH] mm/mremap: correctly account old mapping after MREMAP_DONTUNMAP remap

[Lorenzo Stoakes]

On Tue, Oct 14, 2025 at 10:41:18AM +0100, Pedro Falcato wrote:
> On Mon, Oct 13, 2025 at 05:58:36PM +0100, Lorenzo Stoakes wrote:
> > 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 memor), there is no reason to touch any other VMA
>                         memory
> > 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.
> >
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>
> Reviewed-by: Pedro Falcato <pfalcato@suse.de>

Thanks!

>
> Looks good, thanks! Should we add a test for it?

I considered that, but this is fundamental behaviour and so is very unlikely to
regress so doesn't seem really worth it.

>
> --
> Pedro

Cheers, Lorenzo