mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>,
	 "Liam R. Howlett" <liam@infradead.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	 Jann Horn <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>,
	 Brian Geffon <bgeffon@google.com>,
	Minchan Kim <minchan@kernel.org>,
	 Kiryl Shutsemau <kas@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	 "Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
	stable@vger.kernel.org
Subject: [PATCH 0/2] mm/mremap: fix two issues with MREMAP_DONTUNMAP
Date: Sun, 20 Sep 2026 15:13:09 +0100	[thread overview]
Message-ID: <20260920-fix-dontunmap-partial-self-merge-v1-0-6ffb556f8f8b@kernel.org> (raw)

The MREMAP_DONTUNMAP feature is highly unusual in that it permits mremap()
operations that keep the original VMA in place.

Historically this has led to a lot of bugs where non-obvious interactions
occur between existing mremap() operations and the original VMA.

Commit 397432cab17b ("mm/mremap: account mm->locked_vm correctly for
MREMAP_DONTUNMAP") fixed an accidentally introduced bug around
mm->locked_vm accounting, but this wasn't the only issue.

And thus history repeats itself, as it turns out that mm->locked_vm
accounting is broken by MREMAP_DONTUNMAP yet again by two further cases,
and has been broken ever since the feature was introduced.

Both relate to the fact that VMA_LOCKED_BIT is cleared on the source
VMA (it has to be as all page tables are moved):

1. If an unfaulted VMA_LOCKONFAULT_BIT anonymous VMA self-merges it
   clears the VMA_LOCKED_BIT flag and permanently leaks mm->locked_vm
   pages.

2. If a partial mremap() is performed on a locked VMA there is a leak equal
   to the number of pages not copied.

(Both for MREMAP_DONTUNMAP operations only)

Both issues can be fixed by treating the source range as distinct from the
destination range, which is the definition of what MREMAP_DONTUNMAP does so
is appropriate.

In case 1, simply disallow the self-merge, keeping adjacent source and
destination VMAs distinct.

In case 2, split the source range ahead of time, so accounting is always
correct.

Both changes were tested locally and confirmed to fix the issues.

For the purposes of a backport, the fixes are kept distinct, a follow-up
series can add self-tests.

Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
Lorenzo Stoakes (ARM) (2):
      mm/mremap: fix locked_vm leak from MREMAP_DONTUNMAP self-merge
      mm/mremap: fix locked_vm leak by splitting VMA for MREMAP_DONTUNMAP

 mm/mremap.c                   | 87 +++++++++++++++++++++++++++----------------
 mm/vma.c                      | 19 +++++++++-
 mm/vma.h                      |  7 +++-
 tools/testing/vma/tests/vma.c | 10 ++---
 4 files changed, 83 insertions(+), 40 deletions(-)
---
base-commit: a3d0117e02bfa1c3bb6c50e7afe42bbecdbb3459
change-id: 20260920-fix-dontunmap-partial-self-merge-74a98b1d5a65

Best regards,
-- 
Lorenzo Stoakes (ARM) <ljs@kernel.org>


             reply	other threads:[~2026-09-20 14:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-20 14:13 Lorenzo Stoakes (ARM) [this message]
2026-09-20 14:13 ` [PATCH 1/2] mm/mremap: fix locked_vm leak from MREMAP_DONTUNMAP self-merge Lorenzo Stoakes (ARM)
2026-09-27 14:53   ` Jose A. Perez de Azpillaga
2026-09-28 10:45   ` Kiryl Shutsemau
2026-09-28 10:47     ` Lorenzo Stoakes (ARM)
2026-09-28 11:00   ` Pedro Falcato
2026-09-20 14:13 ` [PATCH 2/2] mm/mremap: fix locked_vm leak by splitting VMA for MREMAP_DONTUNMAP Lorenzo Stoakes (ARM)
2026-09-27 15:06   ` Jose A. Perez de Azpillaga
2026-09-28 11:01   ` Kiryl Shutsemau
2026-09-28 11:08   ` Pedro Falcato
2026-09-26 20:53 ` [PATCH 0/2] mm/mremap: fix two issues with MREMAP_DONTUNMAP Andrew Morton
2026-09-30 15:59 ` Anirudh Srinivasan
2026-09-30 16:04   ` Lorenzo Stoakes (ARM)
2026-09-30 18:24     ` Lorenzo Stoakes (ARM)

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=20260920-fix-dontunmap-partial-self-merge-v1-0-6ffb556f8f8b@kernel.org \
    --to=ljs@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bgeffon@google.com \
    --cc=jannh@google.com \
    --cc=kas@kernel.org \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=pfalcato@suse.de \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@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

all inboxes | Powered by JetHome®