[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <41754dfe-3be7-f64e-45c9-2525d3b20d62@i-love.sakura.ne.jp>
Date: Tue, 9 Oct 2018 22:14:24 +0900
From: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To: Michal Hocko <mhocko@...nel.org>
Cc: ytk.lee@...sung.com, "linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>,
David Rientjes <rientjes@...gle.com>,
Vladimir Davydov <vdavydov.dev@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] mm, oom_adj: avoid meaningless loop to find processes
sharing mm
On 2018/10/09 21:58, Michal Hocko wrote:
> On Tue 09-10-18 21:52:12, Tetsuo Handa wrote:
>> On 2018/10/09 20:10, Michal Hocko wrote:
>>> On Tue 09-10-18 19:00:44, Tetsuo Handa wrote:
>>>>> 2) add OOM_SCORE_ADJ_MIN and do not kill tasks sharing mm and do not
>>>>> reap the mm in the rare case of the race.
>>>>
>>>> That is no problem. The mistake we made in 4.6 was that we updated oom_score_adj
>>>> to -1000 (and allowed unprivileged users to OOM-lockup the system).
>>>
>>> I do not follow.
>>>
>>
>> http://tomoyo.osdn.jp/cgi-bin/lxr/source/mm/oom_kill.c?v=linux-4.6.7#L493
>
> Ahh, so you are not referring to the current upstream code. Do you see
> any specific problem with the current one (well, except for the possible
> race which I have tried to evaluate).
>
Yes. "task_will_free_mem(current) in out_of_memory() returns false due to MMF_OOM_SKIP
being already set" is a problem for clone(CLONE_VM without CLONE_THREAD/CLONE_SIGHAND)
with the current code.
Powered by blists - more mailing lists