Thread (11 messages) 11 messages, 4 authors, 2018-08-28

Re: [PATCH] mm, oom: OOM victims do not need to select next OOM victim unless __GFP_NOFAIL.

From: Michal Hocko <mhocko@suse.com>
Date: 2018-08-20 11:10:19

On Mon 20-08-18 20:02:30, Tetsuo Handa wrote:
On 2018/08/20 19:53, Michal Hocko wrote:
quoted
On Mon 20-08-18 19:37:45, Tetsuo Handa wrote:
quoted
Commit 696453e66630ad45 ("mm, oom: task_will_free_mem should skip
oom_reaped tasks") changed to select next OOM victim as soon as
MMF_OOM_SKIP is set. But since OOM victims can try ALLOC_OOM allocation
and then give up (if !memcg OOM) or can use forced charge and then retry
(if memcg OOM), OOM victims do not need to select next OOM victim unless
they are doing __GFP_NOFAIL allocations.
I do not like this at all. It seems hackish to say the least. And more
importantly...
quoted
This is a quick mitigation because syzbot is hitting WARN(1) caused by
this race window [1]. More robust fix (e.g. make it possible to reclaim
more memory before MMF_OOM_SKIP is set, wait for some more after
MMF_OOM_SKIP is set) is a future work.
.. there is already a patch (by Johannes) for that warning IIRC.
You mean http://lkml.kernel.org/r/20180808144515.GA9276@cmpxchg.org ?
Yes
But I can't find that patch in linux-next.git . And as far as I know,
no patch was sent to linux.git for handling this problem. Therefore,
I wrote this patch so that we can apply for 4.19-rc1.
I am pretty sure Johannes will post them later after merge window
closes.
-- 
Michal Hocko
SUSE Labs
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help