tmpfs: fix spurious ENOSPC when racing with unswap
commite69ce03f62c57295465701bb86e0bca560944764
authorHugh Dickins <hughd@google.com>
Wed, 11 May 2011 22:13:38 +0000 (11 15:13 -0700)
committerGreg Kroah-Hartman <gregkh@suse.de>
Sat, 21 May 2011 22:13:24 +0000 (21 15:13 -0700)
tree27fd7cad0efec148f2e134a5d56b0d3bcac8e94f
parenta1cae297f2bfede2268dee6ce994ef3d861db9ac
tmpfs: fix spurious ENOSPC when racing with unswap

commit 59a16ead572330deb38e5848151d30ed1af754bc upstream.

Testing the shmem_swaplist replacements for igrab() revealed another bug:
writes to /dev/loop0 on a tmpfs file which fills its filesystem were
sometimes failing with "Buffer I/O error"s.

These came from ENOSPC failures of shmem_getpage(), when racing with
swapoff: the same could happen when racing with another shmem_getpage(),
pulling the page in from swap in between our find_lock_page() and our
taking the info->lock (though not in the single-threaded loop case).

This is unacceptable, and surprising that I've not noticed it before:
it dates back many years, but (presumably) was made a lot easier to
reproduce in 2.6.36, which sited a page preallocation in the race window.

Fix it by rechecking the page cache before settling on an ENOSPC error.

Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
mm/shmem.c