On Wed 25-03-15 02:17:14, Johannes Weiner wrote:
> __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.
This one slipped through. Sorry.
> Signed-off-by: Johannes Weiner <hannes@xxxxxxxxxxx>
> Suggested-by: Andrea Arcangeli <aarcange@xxxxxxxxxx>
Acked-by: Michal Hocko <mhocko@xxxxxxx>
> ---
> 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
>
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>