From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Hocko Subject: Re: Possible mem cgroup bug in kernels between 4.18.0 and 5.3-rc1. Date: Mon, 5 Aug 2019 16:26:22 +0200 Message-ID: <20190805142622.GR7597@dhcp22.suse.cz> References: <20190802144110.GL6461@dhcp22.suse.cz> <5DE6F4AE-F3F9-4C52-9DFC-E066D9DD5EDC@apple.com> <20190802191430.GO6461@dhcp22.suse.cz> <20190805084228.GB7597@dhcp22.suse.cz> <7e3c0399-c091-59cd-dbe6-ff53c7c8adc9@i-love.sakura.ne.jp> <20190805114434.GK7597@dhcp22.suse.cz> <0b817204-29f4-adfb-9b78-4fec5fa8f680@i-love.sakura.ne.jp> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <0b817204-29f4-adfb-9b78-4fec5fa8f680@i-love.sakura.ne.jp> Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tetsuo Handa Cc: Andrew Morton , Masoud Sharbiani , Greg KH , hannes@cmpxchg.org, vdavydov.dev@gmail.com, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org On Mon 05-08-19 23:00:12, Tetsuo Handa wrote: > On 2019/08/05 20:44, Michal Hocko wrote: > >> Allowing forced charge due to being unable to invoke memcg OOM killer > >> will lead to global OOM situation, and just returning -ENOMEM will not > >> solve memcg OOM situation. > > > > Returning -ENOMEM would effectivelly lead to triggering the oom killer > > from the page fault bail out path. So effectively get us back to before > > 29ef680ae7c21110. But it is true that this is riskier from the > > observability POV when a) the OOM path wouldn't point to the culprit and > > b) it would leak ENOMEM from g-u-p path. > > > > Excuse me? But according to my experiment, below code showed flood of > "Returning -ENOMEM" message instead of invoking the OOM killer. > I didn't find it gets us back to before 29ef680ae7c21110... You would need to declare OOM_ASYNC to return ENOMEM properly from the charge (which is effectivelly a revert of 29ef680ae7c21110 for NOFS allocations). Something like the following diff --git a/mm/memcontrol.c b/mm/memcontrol.c index ba9138a4a1de..cc34ff0932ce 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1797,7 +1797,7 @@ static enum oom_status mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int * Please note that mem_cgroup_out_of_memory might fail to find a * victim and then we have to bail out from the charge path. */ - if (memcg->oom_kill_disable) { + if (memcg->oom_kill_disable || !(mask & __GFP_FS)) { if (!current->in_user_fault) return OOM_SKIPPED; css_get(&memcg->css); I am quite surprised that your patch didn't trigger the global OOM though. It might mean that ENOMEM doesn't propagate all the way down to the #PF handler for this path for some reason. Anyway what I meant to say is that returning ENOMEM has the observable issues as well. -- Michal Hocko SUSE Labs