[lkml]   [2011]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[PATCH] [177/275] mm: fix possible cause of a page_mapped BUG
2.6.35-longterm review patch.  If anyone has any objections, please let me know.

From: Hugh Dickins <>

commit a3e8cc643d22d2c8ed36b9be7d9c9ca21efcf7f7 upstream.

Robert Swiecki reported a BUG_ON(page_mapped) from a fuzzer, punching
a hole with madvise(,, MADV_REMOVE). That path is under mutex, and
cannot be explained by lack of serialization in unmap_mapping_range().

Reviewing the code, I found one place where vm_truncate_count handling
should have been updated, when I switched at the last minute from one
way of managing the restart_addr to another: mremap move changes the
virtual addresses, so it ought to adjust the restart_addr.

But rather than exporting the notion of restart_addr from memory.c, or
converting to restart_pgoff throughout, simply reset vm_truncate_count
to 0 to force a rescan if mremap move races with preempted truncation.

We have no confirmation that this fixes Robert's BUG,
but it is a fix that's worth making anyway.

Signed-off-by: Hugh Dickins <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Andi Kleen <>
Cc: Kerin Millar <>
Signed-off-by: Greg Kroah-Hartman <>

mm/mremap.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

Index: linux-2.6.35.y/mm/mremap.c
--- linux-2.6.35.y.orig/mm/mremap.c 2011-03-29 22:50:52.769908168 -0700
+++ linux-2.6.35.y/mm/mremap.c 2011-03-29 23:03:01.920251035 -0700
@@ -91,9 +91,7 @@
mapping = vma->vm_file->f_mapping;
- if (new_vma->vm_truncate_count &&
- new_vma->vm_truncate_count != vma->vm_truncate_count)
- new_vma->vm_truncate_count = 0;
+ new_vma->vm_truncate_count = 0;


 \ /
  Last update: 2011-03-30 23:35    [W:0.891 / U:0.668 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site