]> git.karo-electronics.de Git - karo-tx-linux.git/commit
mm: fix possible cause of a page_mapped BUG
authorHugh Dickins <hughd@google.com>
Thu, 24 Feb 2011 05:39:49 +0000 (21:39 -0800)
committerGreg Kroah-Hartman <gregkh@suse.de>
Mon, 21 Mar 2011 19:45:31 +0000 (12:45 -0700)
commit1ed9c543aa80a4e42b61ddd02b2a66986660165f
tree106d886184a915052530d1512d81204091dd6256
parent8238f12a32d413d5ad69f2e975972ecb31f7ce70
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>
Cc: Kerin Millar <kerframil@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
mm/mremap.c