Re: [PATCH] mm/mremap: fix locked_vm accounting for MREMAP_DONTUNMAP

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Fri, Aug 28, 2026 at 05:48:22PM +0800, Kunwu Chan wrote:
> From: Kunwu Chan <kunwu.chan@gmail.com>
>
> When mremap() is called with MREMAP_DONTUNMAP on a locked VMA,
> vrm_stat_account() increments mm->locked_vm for the new VMA while the
> source VMA is still marked VM_LOCKED.
>
> For a normal mremap(), the source VMA is subsequently unmapped and the
> munmap path decrements mm->locked_vm, balancing this accounting.
>
> With MREMAP_DONTUNMAP, the source VMA is left in place and
> dontunmap_complete() clears VMA_LOCKED_MASK.  When the source VMA is
> subsequently unmapped, VMA_LOCKED_BIT is already clear, so the munmap
> path does not undo the increment from vrm_stat_account().  This leaves
> mm->locked_vm over-accounted.
>
> Undo the locked_vm increment in dontunmap_complete() before clearing
> VMA_LOCKED_MASK.  MREMAP_DONTUNMAP requires old_len == new_len, and
> only VMA_LOCKED_BIT is checked to match the accounting performed by
> vrm_stat_account().

Hmm I don't love this approach.

>
> Fixes: b714ccb02a76 ("mm/mremap: complete refactor of move_vma()")

Are you certain that my rework patch was what introduced it?

> Cc: stable@vger.kernel.org
> Signed-off-by: Kunwu Chan <kunwu.chan@gmail.com>

In general while the patch doesn't seem super AI-y I do see a sudden upswing in
patches from you in 2026 so I do have to ask whether LLMs were used? If so
please follow https://docs.kernel.org/process/coding-assistants.html

(I hate having to say these things but hey, it's 2026, so.)

I'm kind of inclined to do a fix myself a different way here.

Given it's going to be a backported patch and you're relatively new to mm, I
feel like this is the safer route, sorry about that.

Happy to add a Reported-by/Closes for this however.

> ---
>  mm/mremap.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/mm/mremap.c b/mm/mremap.c
> index e8df5cdb0ac..37ea5ee1986 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -1334,6 +1334,14 @@ 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;
>
> +	/*
> +	 * vrm_stat_account() accounted the new VMA while the source VMA
> +	 * was still locked.  Since DONTUNMAP leaves the source VMA in
> +	 * place after clearing VMA_LOCKED_MASK, undo that accounting here.
> +	 */
> +	if (vma_test(vrm->vma, VMA_LOCKED_BIT))
> +		vrm->vma->vm_mm->locked_vm -= vrm->old_len >> PAGE_SHIFT;
> +

I don't love this as an approach in general.

As above, I think I will address this slightly differently.

>  	/* We always clear VMA_LOCKED[ONFAULT]_BIT on the old VMA. */
>  	vma_clear_flags_mask(vrm->vma, VMA_LOCKED_MASK);
>
> @@ -1343,8 +1351,6 @@ static void dontunmap_complete(struct vma_remap_struct *vrm,
>  	 */
>  	if (new_vma != vrm->vma && start == old_start && end == old_end)
>  		unlink_anon_vmas(vrm->vma);
> -
> -	/* Because we won't unmap we don't need to touch locked_vm. */
>  }
>
>  static unsigned long move_vma(struct vma_remap_struct *vrm)
> --
> 2.43.0
>

--
Cheers, Lorenzo