[PATCH 1/2] mm: consolidate GFP_NOFAIL checks in the allocator slowpath

2016-12-16 Thread Michal Hocko
From: Michal Hocko Tetsuo Handa has pointed out that 0a0337e0d1d1 ("mm, oom: rework oom detection") has subtly changed semantic for costly high order requests with __GFP_NOFAIL and withtout __GFP_REPEAT and those can fail right now. My code inspection didn't reveal any such

[PATCH 1/2] mm: consolidate GFP_NOFAIL checks in the allocator slowpath

2016-12-16 Thread Michal Hocko
From: Michal Hocko Tetsuo Handa has pointed out that 0a0337e0d1d1 ("mm, oom: rework oom detection") has subtly changed semantic for costly high order requests with __GFP_NOFAIL and withtout __GFP_REPEAT and those can fail right now. My code inspection didn't reveal any such users in the tree but

[PATCH 1/2] mm: consolidate GFP_NOFAIL checks in the allocator slowpath

2016-12-01 Thread Michal Hocko
From: Michal Hocko Tetsuo Handa has pointed out that 0a0337e0d1d1 ("mm, oom: rework oom detection") has subtly changed semantic for costly high order requests with __GFP_NOFAIL and withtout __GFP_REPEAT and those can fail right now. My code inspection didn't reveal any such

[PATCH 1/2] mm: consolidate GFP_NOFAIL checks in the allocator slowpath

2016-12-01 Thread Michal Hocko
From: Michal Hocko Tetsuo Handa has pointed out that 0a0337e0d1d1 ("mm, oom: rework oom detection") has subtly changed semantic for costly high order requests with __GFP_NOFAIL and withtout __GFP_REPEAT and those can fail right now. My code inspection didn't reveal any such users in the tree but