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 <[email protected]> > Suggested-by: Andrea Arcangeli <[email protected]> Acked-by: Michal Hocko <[email protected]> > --- > 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
