Unionfs: mmap fixes to unionfs_writepage
authorErez_Zadok <ezk@cs.sunysb.edu>
Tue, 31 Jul 2007 07:29:50 +0000 (03:29 -0400)
committerErez Zadok <ezk@cs.sunysb.edu>
Fri, 29 Apr 2011 02:24:26 +0000 (22:24 -0400)
commit9b969262a30b2a849967200a5f9395632787b9e6
tree0282580481488e4a3fd3c0247d360c617fed87f5
parentc0238a08e76f0c2e68808410843d8eeb60b45ae0
Unionfs: mmap fixes to unionfs_writepage

This patch fixes hangs when calling sync(2) on memory-pressured systems.

Call find_lock_page instead of grab_cache_page.  We used to call
grab_cache_page(), but that was unnecessary as it would have tried to create
a new lower page if it didn't exist, leading to deadlocks (esp. under
memory-pressure conditions, when it is really a bad idea to *consume* more
memory).  Instead, we assume the lower page exists, and if we can find it,
then we ->writepage on it; if we can't find it, then it couldn't have
disappeared unless the kernel already flushed it, in which case we're still
OK.  This is especially correct if wbc->sync_mode is WB_SYNC_NONE (as per
Documentation/filesystems/vfs.txt).  If we can't flush our page because we
can't find a lower page, then at least we re-mark our page as dirty, and
return AOP_WRITEPAGE_ACTIVATE as the VFS expects us to.  (Note, if in the
future it'd turn out that we have to find a lower page no matter what, then
we'd have to resort to RAIF's page pointer flipping trick.)

Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu>
fs/unionfs/mmap.c