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

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

On 2018/08/20 20:10, Michal Hocko wrote:
> On Mon 20-08-18 20:02:30, Tetsuo Handa wrote:
>> On 2018/08/20 19:53, Michal Hocko wrote:
>>> On Mon 20-08-18 19:37:45, Tetsuo Handa wrote:
>>>> 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...
>>>
>>>> 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.
> 

But Johannes' patch will not prevent the OOM killer from needlessly selecting
next OOM victim, will it? I still think we can apply my patch in order to prevent
the OOM killer from needlessly selecting next OOM victim.