From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f197.google.com (mail-wr0-f197.google.com [209.85.128.197]) by kanga.kvack.org (Postfix) with ESMTP id F110A6B0005 for ; Tue, 24 Apr 2018 16:13:56 -0400 (EDT) Received: by mail-wr0-f197.google.com with SMTP id k16-v6so20596522wrh.6 for ; Tue, 24 Apr 2018 13:13:56 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id 5si227055edu.421.2018.04.24.13.13.55 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 24 Apr 2018 13:13:55 -0700 (PDT) Date: Tue, 24 Apr 2018 14:13:52 -0600 From: Michal Hocko Subject: Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap Message-ID: <20180424201352.GV17484@dhcp22.suse.cz> References: <20180419063556.GK17484@dhcp22.suse.cz> <20180420082349.GW17484@dhcp22.suse.cz> <20180420124044.GA17484@dhcp22.suse.cz> <201804221248.CHE35432.FtOMOLSHOFJFVQ@I-love.SAKURA.ne.jp> <20180424130432.GB17484@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes Cc: Andrew Morton , Tetsuo Handa , Andrea Arcangeli , guro@fb.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org On Tue 24-04-18 13:01:03, David Rientjes wrote: > On Tue, 24 Apr 2018, Michal Hocko wrote: > > > Is there any reason why we cannot simply call __oom_reap_task_mm as we > > have it now? mmap_sem for read shouldn't fail here because this is the > > last reference of the mm and we are past the ksm and khugepaged > > synchronizations. So unless my jed laged brain fools me the patch should > > be as simple as the following (I haven't tested it at all). > > > > I wanted to remove all per task checks because they are now irrelevant: > this would be the first dependency that exit_mmap() has on any > task_struct, which isn't intuitive -- we simply want to exit the mmap. > There's no requirement that current owns the mm other than this. There is no such requirement in the __oom_reap_task_mm. The given task is used for reporting purposes. > I wanted > to avoid the implicit dependency on MMF_OOM_SKIP and make it explicit in > the exit path to be matched with the oom reaper. Well, I find it actually better that the code is not explicit about MMF_OOM_SKIP. The whole thing happens in the oom proper which should be really preferable. The whole synchronization is then completely transparent to the oom (including the oom lock etc). > I didn't want anything > additional printed to the kernel log about oom reaping unless the > oom_reaper actually needed to intervene, which is useful knowledge outside > of basic exiting. Can we shave all those parts as follow ups and make the fix as simple as possible? > My patch has passed intensive testing on both x86 and powerpc, so I'll ask > that it's pushed for 4.17-rc3. Many thanks to Tetsuo for the suggestion > on calling __oom_reap_task_mm() from exit_mmap(). Yeah, but your patch does have a problem with blockable mmu notifiers IIUC. -- Michal Hocko SUSE Labs