mm/mempolicy: fix wrong mmap_read_unlock() in migrate_to_node()
Subsystems (3)
David Hildenbrand (Arm)
maintainerPATCH 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.
--- 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_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
Quoted 8 lines · David Hildenbrand (Arm)
The backport of commit
091c1dd2d4df("mm/mempolicy: fixmigrate_to_node()assuming there is at least one VMA in a MM") contains an error:migrate_to_node()does not lock themmap_lockitself, 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")Reported-by Li Ying <[email protected]>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]>Cc <[email protected]>Signed-off-by David Hildenbrand (Arm) <[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@@ -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
Quoted 8 lines · David Hildenbrand (Arm)
The backport of commit
091c1dd2d4df("mm/mempolicy: fixmigrate_to_node()assuming there is at least one VMA in a MM") contains an error:migrate_to_node()does not lock themmap_lockitself, 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")Reported-by Li Ying <[email protected]>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]>Cc <[email protected]>Signed-off-by David Hildenbrand (Arm) <[email protected]>
straight forward, thanks for the quick fix
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.
--- 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_stVM_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