Commit a3e8cc643d22d2c8ed36b9be7d9c9ca21efcf7f7
Committed by
Linus Torvalds
1 parent
2aa15890f3
Exists in
master
and in
39 other branches
mm: fix possible cause of a page_mapped BUG
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>
Showing 1 changed file with 1 additions and 3 deletions Side-by-side Diff
mm/mremap.c
... | ... | @@ -94,9 +94,7 @@ |
94 | 94 | */ |
95 | 95 | mapping = vma->vm_file->f_mapping; |
96 | 96 | spin_lock(&mapping->i_mmap_lock); |
97 | - if (new_vma->vm_truncate_count && | |
98 | - new_vma->vm_truncate_count != vma->vm_truncate_count) | |
99 | - new_vma->vm_truncate_count = 0; | |
97 | + new_vma->vm_truncate_count = 0; | |
100 | 98 | } |
101 | 99 | |
102 | 100 | /* |