holepunch: fix disconnected pages after second truncate
commit42988ea6a81e888a6aa28549071e00400b68f4f7
authorHugh Dickins <hugh@veritas.com>
Fri, 13 Apr 2007 17:27:10 +0000 (13 18:27 +0100)
committerGreg Kroah-Hartman <gregkh@suse.de>
Wed, 2 May 2007 00:05:55 +0000 (1 17:05 -0700)
tree60aff7bbeec963e22509d5f8d6b967fb741a53e7
parent32576fd4ae53e17af4ca814f7876372a96266b37
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>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
mm/shmem.c