| From | Andi Kleen <> | Subject | [PATCH] [177/275] mm: fix possible cause of a page_mapped BUG | Date | Wed, 30 Mar 2011 14:07:00 -0700 (PDT) |
| |
2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------ From: Hugh Dickins <hughd@google.com>
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 <hughd@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Kerin Millar <kerframil@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
--- 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; spin_lock(&mapping->i_mmap_lock); - 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; } /*
|