On Mon, 16 Nov 2015, [email protected] wrote: > From: Michal Hocko <[email protected]> > > __alloc_pages_slowpath is looping over ALLOC_NO_WATERMARKS requests if > __GFP_NOFAIL is requested. This is fragile because we are basically > relying on somebody else to make the reclaim (be it the direct reclaim > or OOM killer) for us. The caller might be holding resources (e.g. > locks) which block other other reclaimers from making any progress for > example. Remove the retry loop and rely on __alloc_pages_slowpath to > invoke all allowed reclaim steps and retry logic. > > We have to be careful about __GFP_NOFAIL allocations from the > PF_MEMALLOC context even though this is a very bad idea to begin with > because no progress can be gurateed at all. We shouldn't break the > __GFP_NOFAIL semantic here though. It could be argued that this is > essentially GFP_NOWAIT context which we do not support but PF_MEMALLOC > is much harder to check for existing users because they might happen > deep down the code path performed much later after setting the flag > so we cannot really rule out there is no kernel path triggering this > combination. > > Acked-by: Mel Gorman <[email protected]> > Signed-off-by: Michal Hocko <[email protected]>
Acked-by: David Rientjes <[email protected]> It'll be scary if anything actually relies on this, but I think it's more correct. -- 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/
