diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2009-01-29 17:46:42 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2009-01-29 17:46:42 -0800 |
commit | de33c8db5910cda599899dd431cc30d7c1018cbf (patch) | |
tree | 4ee9ba8685bae5d1719a3158284d0c197c83afde /drivers/misc | |
parent | 18e352e4a73465349711a9324767e1b2453383e2 (diff) | |
download | linux-3.10-de33c8db5910cda599899dd431cc30d7c1018cbf.tar.gz linux-3.10-de33c8db5910cda599899dd431cc30d7c1018cbf.tar.bz2 linux-3.10-de33c8db5910cda599899dd431cc30d7c1018cbf.zip |
Fix OOPS in mmap_region() when merging adjacent VM_LOCKED file segments
As of commit ba470de43188cdbff795b5da43a1474523c6c2fb ("map: handle
mlocked pages during map, remap, unmap") we now use the 'vma' variable
at the end of mmap_region() to handle the page-in of newly mapped
mlocked pages.
However, if we merged adjacent vma's together, the vma we're using may
be stale. We historically consciously avoided using it after the merge
operation, but that got overlooked when redoing the locked page
handling.
This commit simplifies mmap_region() by doing any vma merges early,
avoiding the issue entirely, and 'vma' will always be valid. As pointed
out by Hugh Dickins, this depends on any drivers that change the page
offset of flags to have set one of the VM_SPECIAL bits (so that they
cannot trigger the early merge logic), but that's true in general.
Reported-and-tested-by: Maksim Yevmenkin <maksim.yevmenkin@gmail.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/misc')
0 files changed, 0 insertions, 0 deletions