summaryrefslogtreecommitdiffstats
path: root/mm/huge_memory.c
diff options
context:
space:
mode:
authorHugh Dickins <hughd@google.com>2014-06-23 13:22:06 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2014-06-23 16:47:44 -0700
commitf00cdc6df7d7cfcabb5b740911e6788cb0802bdb (patch)
tree2d540f918e013b5dcca920e904c264c703c794eb /mm/huge_memory.c
parentf72e7dcdd25229446b102e587ef2f826f76bff28 (diff)
downloadop-kernel-dev-f00cdc6df7d7cfcabb5b740911e6788cb0802bdb.zip
op-kernel-dev-f00cdc6df7d7cfcabb5b740911e6788cb0802bdb.tar.gz
shmem: fix faulting into a hole while it's punched
Trinity finds that mmap access to a hole while it's punched from shmem can prevent the madvise(MADV_REMOVE) or fallocate(FALLOC_FL_PUNCH_HOLE) from completing, until the reader chooses to stop; with the puncher's hold on i_mutex locking out all other writers until it can complete. It appears that the tmpfs fault path is too light in comparison with its hole-punching path, lacking an i_data_sem to obstruct it; but we don't want to slow down the common case. Extend shmem_fallocate()'s existing range notification mechanism, so shmem_fault() can refrain from faulting pages into the hole while it's punched, waiting instead on i_mutex (when safe to sleep; or repeatedly faulting when not). [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Hugh Dickins <hughd@google.com> Reported-by: Sasha Levin <sasha.levin@oracle.com> Tested-by: Sasha Levin <sasha.levin@oracle.com> Cc: Dave Jones <davej@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/huge_memory.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud