summaryrefslogtreecommitdiffstats
path: root/mm/madvise.c
diff options
context:
space:
mode:
authorHugh Dickins <hugh@veritas.com>2007-03-29 10:20:37 +0200
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-03-29 17:22:25 +0200
commit16a100190d39592d1d56ff5a0b978b20288c3427 (patch)
tree63af0d78497e540f096262da83ed44ddbe1eab94 /mm/madvise.c
parent[PATCH] holepunch: fix shmem_truncate_range punch locking (diff)
downloadlinux-16a100190d39592d1d56ff5a0b978b20288c3427.tar.xz
linux-16a100190d39592d1d56ff5a0b978b20288c3427.zip
[PATCH] holepunch: fix disconnected pages after second truncate
shmem_truncate_range has its own truncate_inode_pages_range, to free any pages racily instantiated while it was in progress: a SHMEM_PAGEIN flag is set when this might have happened. But holepunching gets no chance to clear that flag at the start of vmtruncate_range, so it's always set (unless a truncate came just before), so holepunch almost always does this second truncate_inode_pages_range. shmem holepunch has unlikely swap<->file races hereabouts whatever we do (without a fuller rework than is fit for this release): I was going to skip the second truncate in the punch_hole case, but Miklos points out that would make holepunch correctness more vulnerable to swapoff. So keep the second truncate, but follow it by an unmap_mapping_range to eliminate the disconnected pages (freed from pagecache while still mapped in userspace) that it might have left behind. Signed-off-by: Hugh Dickins <hugh@veritas.com> Cc: Miklos Szeredi <mszeredi@suse.cz> Cc: Badari Pulavarty <pbadari@us.ibm.com> Cc: Nick Piggin <npiggin@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/madvise.c')
0 files changed, 0 insertions, 0 deletions