linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Xu <peterx@redhat.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>, Jann Horn <jannh@google.com>,
	Pedro Falcato <pfalcato@suse.de>, Rik van Riel <riel@surriel.com>,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: [PATCH 08/10] mm/mremap: clean up mlock populate behaviour
Date: Mon,  7 Jul 2025 06:27:51 +0100	[thread overview]
Message-ID: <1bea4f7b5093d603ff323570076142eaabc8a480.1751865330.git.lorenzo.stoakes@oracle.com> (raw)
In-Reply-To: <cover.1751865330.git.lorenzo.stoakes@oracle.com>

When an mlock()'d VMA is expanded, we need to populate the expanded region
to maintain the contract that all mlock()'d memory is present (albeit -
with some period after mmap unlock where the expanded part of the mapping
remains unfaulted).

The current implementation is very unclear, so make it absolutely explicit
under what circumstances we do this.

Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
 mm/mremap.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/mm/mremap.c b/mm/mremap.c
index 3678f21c2c36..28e776cddc08 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -65,7 +65,7 @@ struct vma_remap_struct {
 
 	/* Internal state, determined in do_mremap(). */
 	unsigned long delta;		/* Absolute delta of old_len,new_len. */
-	bool mlocked;			/* Was the VMA mlock()'d? */
+	bool populate_expand;		/* mlock()'d expanded, must populate. */
 	enum mremap_type remap_type;	/* expand, shrink, etc. */
 	bool mmap_locked;		/* Is mm currently write-locked? */
 	unsigned long charged;		/* If VM_ACCOUNT, # pages to account. */
@@ -1010,10 +1010,8 @@ static void vrm_stat_account(struct vma_remap_struct *vrm,
 	struct vm_area_struct *vma = vrm->vma;
 
 	vm_stat_account(mm, vma->vm_flags, pages);
-	if (vma->vm_flags & VM_LOCKED) {
+	if (vma->vm_flags & VM_LOCKED)
 		mm->locked_vm += pages;
-		vrm->mlocked = true;
-	}
 }
 
 /*
@@ -1653,6 +1651,10 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
 	if (new_len <= old_len)
 		return 0;
 
+	/* We are expanding and the VMA is mlock()'d so we need to populate. */
+	if (vma->vm_flags & VM_LOCKED)
+		vrm->populate_expand = true;
+
 	/* Need to be careful about a growing mapping */
 	pgoff = (addr - vma->vm_start) >> PAGE_SHIFT;
 	pgoff += vma->vm_pgoff;
@@ -1773,7 +1775,8 @@ static unsigned long do_mremap(struct vma_remap_struct *vrm)
 	if (vrm->mmap_locked)
 		mmap_write_unlock(mm);
 
-	if (!failed && vrm->mlocked && vrm->new_len > vrm->old_len)
+	/* VMA mlock'd + was expanded, so populated expanded region. */
+	if (!failed && vrm->populate_expand)
 		mm_populate(vrm->new_addr + vrm->old_len, vrm->delta);
 
 	notify_uffd(vrm, failed);
-- 
2.50.0



  parent reply	other threads:[~2025-07-07  5:29 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-07  5:27 [PATCH 00/10] mm/mremap: permit mremap() move of multiple VMAs Lorenzo Stoakes
2025-07-07  5:27 ` [PATCH 01/10] mm/mremap: perform some simple cleanups Lorenzo Stoakes
2025-07-10 11:09   ` Vlastimil Babka
2025-07-07  5:27 ` [PATCH 02/10] mm/mremap: refactor initial parameter sanity checks Lorenzo Stoakes
2025-07-10 11:38   ` Vlastimil Babka
2025-07-07  5:27 ` [PATCH 03/10] mm/mremap: put VMA check and prep logic into helper function Lorenzo Stoakes
2025-07-10 13:10   ` Vlastimil Babka
2025-07-07  5:27 ` [PATCH 04/10] mm/mremap: cleanup post-processing stage of mremap Lorenzo Stoakes
2025-07-10 13:49   ` Vlastimil Babka
2025-07-10 15:28     ` Lorenzo Stoakes
2025-07-07  5:27 ` [PATCH 05/10] mm/mremap: use an explicit uffd failure path for mremap Lorenzo Stoakes
2025-07-07  7:56   ` kernel test robot
2025-07-07 10:13     ` Lorenzo Stoakes
2025-07-07 10:20   ` Lorenzo Stoakes
2025-07-10 14:24   ` Vlastimil Babka
2025-07-07  5:27 ` [PATCH 06/10] mm/mremap: check remap conditions earlier Lorenzo Stoakes
2025-07-10 14:36   ` Vlastimil Babka
2025-07-07  5:27 ` [PATCH 07/10] mm/mremap: move remap_is_valid() into check_prep_vma() Lorenzo Stoakes
2025-07-10 14:44   ` Vlastimil Babka
2025-07-07  5:27 ` Lorenzo Stoakes [this message]
2025-07-10 14:47   ` [PATCH 08/10] mm/mremap: clean up mlock populate behaviour Vlastimil Babka
2025-07-07  5:27 ` [PATCH 09/10] mm/mremap: permit mremap() move of multiple VMAs Lorenzo Stoakes
2025-07-09 18:13   ` Liam R. Howlett
2025-07-10 10:41     ` Lorenzo Stoakes
2025-07-11  8:17   ` Mark Brown
2025-07-11  8:22     ` Mark Brown
2025-07-11  8:31       ` Lorenzo Stoakes
2025-07-07  5:27 ` [PATCH 10/10] tools/testing/selftests: extend mremap_test to test multi-VMA mremap Lorenzo Stoakes
2025-07-07  6:12 ` [PATCH 00/10] mm/mremap: permit mremap() move of multiple VMAs Hugh Dickins
2025-07-07 10:31   ` Lorenzo Stoakes
2025-07-07 10:34 ` Lorenzo Stoakes

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=1bea4f7b5093d603ff323570076142eaabc8a480.1751865330.git.lorenzo.stoakes@oracle.com \
    --to=lorenzo.stoakes@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=jannh@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=pfalcato@suse.de \
    --cc=riel@surriel.com \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    /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