summaryrefslogtreecommitdiffstats
path: root/drivers/misc/sgi-xp/xpc_uv.c
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2009-01-29 17:46:42 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2009-01-29 17:46:42 -0800
commitde33c8db5910cda599899dd431cc30d7c1018cbf (patch)
tree4ee9ba8685bae5d1719a3158284d0c197c83afde /drivers/misc/sgi-xp/xpc_uv.c
parent18e352e4a73465349711a9324767e1b2453383e2 (diff)
downloadop-kernel-dev-de33c8db5910cda599899dd431cc30d7c1018cbf.zip
op-kernel-dev-de33c8db5910cda599899dd431cc30d7c1018cbf.tar.gz
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/sgi-xp/xpc_uv.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud