aboutsummaryrefslogtreecommitdiff
path: root/mm/vmscan.c
diff options
context:
space:
mode:
authorKevin Hilman <khilman@linaro.org>2015-09-14 14:16:54 -0700
committerKevin Hilman <khilman@linaro.org>2015-09-14 14:16:54 -0700
commit0e4f19b4e5d6c4801d0ee2c26a5850de1b44f4af (patch)
treecbd277d85dedfe2f64b94c5e385b311e2c017137 /mm/vmscan.c
parent59255ac55ba6ecd195ef97c6bcd1303a7f838c94 (diff)
parent4d869de174c78ae29ca91b41581367c8092d933d (diff)
Diffstat (limited to 'mm/vmscan.c')
-rw-r--r--mm/vmscan.c11
1 files changed, 3 insertions, 8 deletions
diff --git a/mm/vmscan.c b/mm/vmscan.c
index a2fd7e759cb7..233f0011f768 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -730,20 +730,15 @@ static unsigned long shrink_page_list(struct list_head *page_list,
* could easily OOM just because too many pages are in
* writeback and there is nothing else to reclaim.
*
- * Check __GFP_IO, certainly because a loop driver
+ * Require may_enter_fs to wait on writeback, because
+ * fs may not have submitted IO yet. And a loop driver
* thread might enter reclaim, and deadlock if it waits
* on a page for which it is needed to do the write
* (loop masks off __GFP_IO|__GFP_FS for this reason);
* but more thought would probably show more reasons.
- *
- * Don't require __GFP_FS, since we're not going into
- * the FS, just waiting on its writeback completion.
- * Worryingly, ext4 gfs2 and xfs allocate pages with
- * grab_cache_page_write_begin(,,AOP_FLAG_NOFS), so
- * testing may_enter_fs here is liable to OOM on them.
*/
if (global_reclaim(sc) ||
- !PageReclaim(page) || !(sc->gfp_mask & __GFP_IO)) {
+ !PageReclaim(page) || !may_enter_fs) {
/*
* This is slightly racy - end_page_writeback()
* might have just cleared PageReclaim, then