From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755268AbcFPO3v (ORCPT ); Thu, 16 Jun 2016 10:29:51 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:35704 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755178AbcFPO3n (ORCPT ); Thu, 16 Jun 2016 10:29:43 -0400 Date: Thu, 16 Jun 2016 16:29:40 +0200 From: Michal Hocko To: Tetsuo Handa Cc: linux-mm@kvack.org, rientjes@google.com, oleg@redhat.com, vdavydov@parallels.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 07/10] mm, oom: fortify task_will_free_mem Message-ID: <20160616142940.GK6836@dhcp22.suse.cz> References: <1465473137-22531-8-git-send-email-mhocko@kernel.org> <201606092218.FCC48987.MFQLVtSHJFOOFO@I-love.SAKURA.ne.jp> <20160609142026.GF24777@dhcp22.suse.cz> <201606111710.IGF51027.OJLSOQtHVOFFFM@I-love.SAKURA.ne.jp> <20160613112746.GD6518@dhcp22.suse.cz> <201606162154.CGE05294.HJQOSMFFVFtOOL@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201606162154.CGE05294.HJQOSMFFVFtOOL@I-love.SAKURA.ne.jp> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 16-06-16 21:54:27, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Sat 11-06-16 17:10:03, Tetsuo Handa wrote: [...] > I still don't like it. current->mm == NULL in > > - if (current->mm && > - (fatal_signal_pending(current) || task_will_free_mem(current))) { > + if (task_will_free_mem(current)) { > > is not highly unlikely. You obviously break commit d7a94e7e11badf84 > ("oom: don't count on mm-less current process") on CONFIG_MMU=n kernels. I still fail to see why you care about that case so much. The heuristic was broken for other reasons before this patch. The patch fixes a class of issues for both mmu and nommu. I can restore the current->mm check for now but the more I am thinking about it the less I am sure the commit you are referring to is evem correct/necessary. It claims that the OOM killer would be stuck because the child would be sitting in the final schedule() until the parent reaps it. That is not true, though, because victim would be unhashed down in release_task() path so it is not visible by the oom killer when it is waiting for the parent. I have completely missed that part when reviewing the patch. Or am I missing something... Anyway, would you be OK with the patch if I added the current->mm check and resolve its necessity in a separate patch? -- Michal Hocko SUSE Labs