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

From: Michal Hocko <mhocko@kernel.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dmitry Vyukov <dvyukov@google.com>,
	linux-mm@kvack.org, Greg Thelen <gthelen@google.com>,
	David Rientjes <rientjes@google.com>,
	syzbot <syzbot+bab151e82a4e973fa325@syzkaller.appspotmail.com>
Subject: Re: [PATCH] mm, oom: OOM victims do not need to select next OOM victim unless __GFP_NOFAIL.
Date: Tue, 28 Aug 2018 15:51:54 +0200	[thread overview]
Message-ID: <20180828135105.GB10349@dhcp22.suse.cz> (raw)
In-Reply-To: <58e0bd2d-71bd-cf46-0929-ef5eb0c6c2bc@i-love.sakura.ne.jp>

On Tue 28-08-18 22:29:56, Tetsuo Handa wrote:
[...]
> The OOM reaper may set MMF_OOM_SKIP without reclaiming any memory (due
> to e.g. mlock()ed memory, shared memory, unable to grab mmap_sem for read).
> We haven't reached to the point where the OOM reaper reclaims all memory
> nor allocating threads wait some more after setting MMF_OOM_SKIP.
> Therefore, this
> 
>   if (tsk_is_oom_victim(current) && !(oc->gfp_mask & __GFP_NOFAIL))
>       return true;
> 
> is the simplest mitigation we can do now.

But this is adding a mess because you pretend to make a forward progress
even the OOM path didn't do anything at all and rely on another kludge
elsewhere to work. This just makes the code fragile for not strong
reason. Yes, this whole area is racy and there are rare corner cases as
you mentioned. I have already mentioned how to deal with some of them
several times. It would be so much more helpful to go after those and
address them rather than post some random hacks and build castles on a
sand.
-- 
Michal Hocko
SUSE Labs