__GFP_NOFAIL allocations can deadlock the OOM killer when they're
holding locks that the OOM victim might need to exit. When that
happens the allocation may never complete, which has disastrous
effects on things like in-flight filesystem transactions.
When the system is OOM, allow __GFP_NOFAIL allocations to dip into the
emergency reserves in the hope that this will allow transactions and
writeback to complete and the deadlock can be avoided.
Signed-off-by: Johannes Weiner <hannes@xxxxxxxxxxx>
Suggested-by: Andrea Arcangeli <aarcange@xxxxxxxxxx>
---
mm/page_alloc.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 3c165016175d..832ad1c7cd4f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2403,9 +2403,17 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order, int alloc_flags,
* from exiting. While allocations can use OOM kills to free
* memory, they can not necessarily rely on their *own* kills
* to make forward progress.
+ *
+ * This last point is crucial for __GFP_NOFAIL allocations.
+ * Since they can't quit, they might actually deadlock, so
+ * give them hail mary access to the emergency reserves.
*/
- alloc_flags &= ~ALLOC_WMARK_MASK;
- alloc_flags |= ALLOC_WMARK_OOM;
+ if (gfp_mask & __GFP_NOFAIL) {
+ alloc_flags |= ALLOC_NO_WATERMARKS;
+ } else {
+ alloc_flags &= ~ALLOC_WMARK_MASK;
+ alloc_flags |= ALLOC_WMARK_OOM;
+ }
out:
mutex_unlock(&oom_lock);
alloc:
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
