On Mon, 16 Nov 2015, mhocko@xxxxxxxxxx wrote: > From: Michal Hocko <mhocko@xxxxxxxx> > > __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 <mgorman@xxxxxxx> > Signed-off-by: Michal Hocko <mhocko@xxxxxxxx> Acked-by: David Rientjes <rientjes@xxxxxxxxxx> It'll be scary if anything actually relies on this, but I think it's more correct. -- 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>