From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <liam@infradead.org>,
Jann Horn <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
sashiko-bot <sashiko-bot@kernel.org>,
Kunwu Chan <kunwu.chan@gmail.com>,
stable@vger.kernel.org
Subject: Re: [PATCH] mm/mremap: account mm->locked_vm correctly for MREMAP_DONTUNMAP
Date: Fri, 28 Aug 2026 15:39:15 +0200 [thread overview]
Message-ID: <5e09ebb1-5dc9-44ce-b997-3b545db727cb@kernel.org> (raw)
In-Reply-To: <20260828-mremap-fix-locked-vm-v1-1-c80be7505d1e@kernel.org>
On 8/28/26 13:20, Lorenzo Stoakes (ARM) wrote:
> When a VMA is mremap()'d with MREMAP_DONTUNMAP set, that results in the VMA
> being copied, but the source VMA not being unmapped.
>
> If the VMA is mlock()'d this is a legal operation, though the source VMA
> has its VMA_LOCKED_BIT cleared.
>
> However this is done in dontunmap_complete(), after mm->locked_vm was
> incremented via vrm_stat_account(), resulting in double-counting.
>
> Worse, this is not even corrected when source VMA is unmapped, due to
> the VMA_LOCKED_BIT flag having been cleared.
>
> This all works fine in the usual mremap() case (without MREMAP_DONTUNMAP),
> as the source VMA is unmapped with VMA_LOCKED_BIT intact, at which time
> mm->locked_vm is decremented accordingly.
>
> Resolve the issue by invoking vrm_stat_account() only after
> dontunmap_complete() has run.
>
> Note that MREMAP_DONTUNMAP requires old_len == new_len, so no need to
> account for a delta in size in this case.
>
> The bug was introduced by commit b714ccb02a76 ("mm/mremap: complete
> refactor of move_vma()") which incorrectly reordered the accounting and the
> clearing of the VMA_LOCKED_BIT flag.
>
> Reported-by: sashiko-bot <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260825-fix-mremap-dontunmap-pgoff-v1-1-39a40b2c98b3@kernel.org
> Reported-by: Kunwu Chan <kunwu.chan@gmail.com>
> Closes: https://lore.kernel.org/all/20260828094823.594279-1-kunwu.chan@linux.dev/
> Fixes: b714ccb02a76 ("mm/mremap: complete refactor of move_vma()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> mm/mremap.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/mm/mremap.c b/mm/mremap.c
> index 2b4b523a86b8..7c368440fafe 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -1355,12 +1355,11 @@ static void dontunmap_complete(struct vma_remap_struct *vrm,
> if (vma_is_anonymous(vma) && !vma->vm_file)
> vma_set_pgoff(vma, pgoff_unfaulted);
> }
> -
> - /* Because we won't unmap we don't need to touch locked_vm. */
> }
>
> static unsigned long move_vma(struct vma_remap_struct *vrm)
> {
> + const bool is_dontunmap = vrm->flags & MREMAP_DONTUNMAP;
> struct mm_struct *mm = current->mm;
> struct vm_area_struct *new_vma;
> unsigned long hiwater_vm;
> @@ -1401,10 +1400,10 @@ static unsigned long move_vma(struct vma_remap_struct *vrm)
> */
> hiwater_vm = mm->hiwater_vm;
>
> - vrm_stat_account(vrm, vrm->new_len);
> - if (unlikely(!err && (vrm->flags & MREMAP_DONTUNMAP)))
> + if (unlikely(is_dontunmap && !err))
> dontunmap_complete(vrm, new_vma);
> - else
> + vrm_stat_account(vrm, vrm->new_len);
> + if (!is_dontunmap || err)
> unmap_source_vma(vrm);
>
> mm->hiwater_vm = hiwater_vm;
>
> ---
> base-commit: aeddb4d52acfcc5ce5e988acd48f2906fe966ca3
> change-id: 20260828-mremap-fix-locked-vm-b8991ffc4181
>
> Best regards,
prev parent reply other threads:[~2026-08-28 13:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-28 11:20 [PATCH] mm/mremap: account mm->locked_vm correctly for MREMAP_DONTUNMAP Lorenzo Stoakes (ARM)
2026-08-28 13:39 ` Vlastimil Babka (SUSE) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5e09ebb1-5dc9-44ce-b997-3b545db727cb@kernel.org \
--to=vbabka@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=jannh@google.com \
--cc=kunwu.chan@gmail.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=pfalcato@suse.de \
--cc=sashiko-bot@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox