diff options
author | Hugh Dickins <hughd@google.com> | 2011-02-23 21:39:49 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2011-02-23 21:55:06 -0800 |
commit | a3e8cc643d22d2c8ed36b9be7d9c9ca21efcf7f7 (patch) | |
tree | d3a10397009baeb3cb1802286049111536dbc221 /kernel/hung_task.c | |
parent | 2aa15890f3c191326678f1bd68af61ec6b8753ec (diff) | |
download | linux-a3e8cc643d22d2c8ed36b9be7d9c9ca21efcf7f7.tar.gz linux-a3e8cc643d22d2c8ed36b9be7d9c9ca21efcf7f7.tar.bz2 linux-a3e8cc643d22d2c8ed36b9be7d9c9ca21efcf7f7.zip |
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>
Diffstat (limited to 'kernel/hung_task.c')
0 files changed, 0 insertions, 0 deletions