Skip to contentSkip to conversation

mm/mempolicy: fix wrong mmap_read_unlock() in migrate_to_node()

PATCH Applied David Hildenbrand (Arm) 4 participants 4 messages Mar 3 – Mar 19

Subsystems (3)
lore
Share & tools
lore

David Hildenbrand (Arm)

author maintainer
#0 lore raw

PATCH 1/1 mm/mempolicy: fix wrong mmap_read_unlock() in migrate_to_node()

The backport of commit 091c1dd2d4df ("mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM") contains an error:
migrate_to_node() does not lock the mmap_lock itself, that is handled by the caller instead.

So let's drop the wrong mmap_read_unlock(). Fortunately, this path is very hard to hit in practice.

Fixes a13b2b9b0b0b ("mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM")
Cc Greg Kroah-Hartman <[email protected]>
Cc Andrew Morton <[email protected]>
Cc Matthew Wilcox <[email protected]>
Cc Christoph Lameter <[email protected]>
Cc Liam R. Howlett <[email protected]>
---
 mm/mempolicy.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
mm/mempolicy.c +1 -3
index 94c74c594d10..d8007e1c2690 100644
@@ -1071,10 +1071,8 @@ static long migrate_to_node(struct mm_struct *mm, int source, int dest,
 
 	VM_BUG_ON(!(flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL)));
 	vma = find_vma(mm, 0);
-	if (unlikely(!vma)) {
-		mmap_read_unlock(mm);
+	if (unlikely(!vma))
 		return 0;
-	}
 
 	/*
 	 * This does not migrate the range, but isolates all pages that
Signature · 1 line
2.43.0
Reviewed-by on v1 1/1
#1 lore raw
Quoted 8 lines · David Hildenbrand (Arm)

The backport of commit 091c1dd2d4df ("mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM") contains an error:
migrate_to_node() does not lock the mmap_lock itself, that is handled by the caller instead.

So let's drop the wrong mmap_read_unlock(). Fortunately, this path is very hard to hit in practice.

Quoted 10 lines
Fixes a13b2b9b0b0b ("mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM")
Cc Greg Kroah-Hartman <[email protected]>
Cc Andrew Morton <[email protected]>
Cc Matthew Wilcox <[email protected]>
Cc Christoph Lameter <[email protected]>
Cc Liam R. Howlett <[email protected]>

Ouch, yeah. The locking is different.

Quoted 23 lines
---
 mm/mempolicy.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
mm/mempolicy.c +1 -3
index 94c74c594d10..d8007e1c2690 100644
@@ -1071,10 +1071,8 @@ static long migrate_to_node(struct mm_struct *mm, int source, int dest,
 
 	VM_BUG_ON(!(flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL)));
 	vma = find_vma(mm, 0);
-	if (unlikely(!vma)) {
-		mmap_read_unlock(mm);
+	if (unlikely(!vma))
 		return 0;
-	}
 
 	/*
 	 * This does not migrate the range, but isolates all pages that
Signature · 1 line
2.43.0
maintainer Reviewed-by on v1 1/1
#2 lore raw
In reply to David Hildenbrand (Arm)
Quoted 8 lines · David Hildenbrand (Arm)

The backport of commit 091c1dd2d4df ("mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM") contains an error:
migrate_to_node() does not lock the mmap_lock itself, that is handled by the caller instead.

So let's drop the wrong mmap_read_unlock(). Fortunately, this path is very hard to hit in practice.

Quoted 10 lines
Fixes a13b2b9b0b0b ("mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM")
Cc Greg Kroah-Hartman <[email protected]>
Cc Andrew Morton <[email protected]>
Cc Matthew Wilcox <[email protected]>
Cc Christoph Lameter <[email protected]>
Cc Liam R. Howlett <[email protected]>

straight forward, thanks for the quick fix

maintainer Applied
#3 lore raw

Patch "mm/mempolicy: fix wrong mmap_read_unlock() in migrate_to_node()" has been added to the 6.6-stable tree

In reply to David Hildenbrand (Arm)

This is a note to let you know that I've just added the patch titled

mm/mempolicy: fix wrong mmap_read_unlock() in migrate_to_node()

to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
mm-mempolicy-fix-wrong-mmap_read_unlock-in-migrate_to_node.patch
and it can be found in the queue-6.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From [email protected] Thu Mar 19 14:49:55 2026
From: "David Hildenbrand (Arm)" <[email protected]>
Date: Tue, 3 Mar 2026 11:12:45 +0100
Subject: mm/mempolicy: fix wrong mmap_read_unlock() in migrate_to_node()
To: [email protected]
Cc: linux-mm <[email protected]>, "David Hildenbrand (Arm)" <[email protected]>, Li Ying <[email protected]>, Greg Kroah-Hartman <[email protected]>, Andrew Morton <[email protected]>, Matthew Wilcox <[email protected]>, Christoph Lameter <[email protected]>, "Liam R . Howlett" <[email protected]>
Message-ID: <[email protected]>

From: "David Hildenbrand (Arm)" <[email protected]>

The backport of commit 091c1dd2d4df ("mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM") contains an error:
migrate_to_node() does not lock the mmap_lock itself, that is handled by the caller instead.

So let's drop the wrong mmap_read_unlock(). Fortunately, this path is very hard to hit in practice.

Fixes a13b2b9b0b0b ("mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM")
Cc Andrew Morton <[email protected]>
Cc Matthew Wilcox <[email protected]>
Cc Christoph Lameter <[email protected]>
---
 mm/mempolicy.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
mm/mempolicy.c +1 -3
@@ -1071,10 +1071,8 @@ static long migrate_to_node(struct mm_st
 
 	VM_BUG_ON(!(flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL)));
 	vma = find_vma(mm, 0);
-	if (unlikely(!vma)) {
-		mmap_read_unlock(mm);
+	if (unlikely(!vma))
 		return 0;
-	}
 
 	/*
 	 * This does not migrate the range, but isolates all pages that

Patches currently in stable-queue which might be from [email protected] are

queue-6.6/mm-mempolicy-fix-wrong-mmap_read_unlock-in-migrate_to_node.patch queue-6.6/mm-tracing-rss_stat-ensure-curr-is-false-from-kthread-context.patch