Michal Hocko wrote: > On Wed 25-02-15 20:22:22, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > This commit hasn't introduced any behavior changes. GFP_NOFAIL > > > allocations fail when OOM killer is disabled since beginning > > > 7f33d49a2ed5 (mm, PM/Freezer: Disable OOM killer when tasks are frozen). > > > > I thought that > > > > - out_of_memory(ac->zonelist, gfp_mask, order, ac->nodemask, false); > > - *did_some_progress = 1; > > + if (out_of_memory(ac->zonelist, gfp_mask, order, ac->nodemask, false)) > > + *did_some_progress = 1; > > > > in commit c32b3cbe0d067a9c "oom, PM: make OOM detection in the freezer > > path raceless" introduced a code path which fails to set > > *did_some_progress to non 0 value. > > But this commit had also the following hunk: > @@ -2317,9 +2315,6 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order, > > *did_some_progress = 0; > > - if (oom_killer_disabled) > - return NULL; > - > > so we even wouldn't get down to out_of_memory and returned with > did_some_progress=0 right away. So the patch hasn't changed the logic. OK. > OK, that would change the bahavior for __GFP_NOFAIL|~__GFP_FS > allocations. The patch from Johannes which reverts GFP_NOFS failure mode > should go to stable and that should be sufficient IMO. > mm-page_alloc-revert-inadvertent-__gfp_fs-retry-behavior-change.patch fixes only ~__GFP_NOFAIL|~__GFP_FS case. I think we need David's version http://marc.info/?l=linux-mm&m=142489687015873&w=2 for 3.19-stable . -- 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>