diff options
| author | Hugh Dickins <hughd@google.com> | 2011-02-23 21:39:49 -0800 |
|---|---|---|
| committer | Paul Gortmaker <paul.gortmaker@windriver.com> | 2011-06-26 12:46:57 -0400 |
| commit | 93a4339b83b8cdaaca71497128bebd4e2e5a04af (patch) | |
| tree | 9c94e3300e66ff585fc9c4d239d5424b98ff9a06 /mm | |
| parent | a9430e99a0038ecae82987ae0258e845beec8f5f (diff) | |
mm: fix possible cause of a page_mapped BUG
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: Paul Gortmaker <paul.gortmaker@windriver.com>
Diffstat (limited to 'mm')
| -rw-r--r-- | mm/mremap.c | 4 |
1 files changed, 1 insertions, 3 deletions
diff --git a/mm/mremap.c b/mm/mremap.c index cde56ee51ef7..10d5f6264514 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -91,9 +91,7 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd, */ 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; } /* |