From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932251AbcFIPPZ (ORCPT ); Thu, 9 Jun 2016 11:15:25 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:21987 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752108AbcFIPPY (ORCPT ); Thu, 9 Jun 2016 11:15:24 -0400 To: mhocko@kernel.org, linux-mm@kvack.org Cc: rientjes@google.com, oleg@redhat.com, vdavydov@parallels.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, mhocko@suse.com Subject: Re: [PATCH 10/10] mm, oom: hide mm which is shared with kthread or global init From: Tetsuo Handa References: <1465473137-22531-1-git-send-email-mhocko@kernel.org> <1465473137-22531-11-git-send-email-mhocko@kernel.org> In-Reply-To: <1465473137-22531-11-git-send-email-mhocko@kernel.org> Message-Id: <201606100015.HBB65678.LSOFFJOFMQHOVt@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Fri, 10 Jun 2016 00:15:18 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Michal Hocko wrote: > The only case where the oom_reaper is not triggered for the oom victim > is when it shares the memory with a kernel thread (aka use_mm) or with > the global init. After "mm, oom: skip vforked tasks from being selected" > the victim cannot be a vforked task of the global init so we are left > with clone(CLONE_VM) (without CLONE_SIGHAND). use_mm() users are quite > rare as well. CONFIG_MMU=n is the other case where the oom_reaper is not triggered for the oom victim. > > In order to guarantee a forward progress for the OOM killer make > sure that this really rare cases will not get into the way and hide > the mm from the oom killer by setting MMF_OOM_REAPED flag for it. > oom_scan_process_thread will ignore any TIF_MEMDIE task if it has > MMF_OOM_REAPED flag set to catch these oom victims. Nobody will set MMF_OOM_REAPED flag if can_oom_reap == true on CONFIG_MMU=n kernel. If a TIF_MEMDIE thread in CONFIG_MMU=n kernel is blocked before exit_oom_victim() in exit_mm() from do_exit() is called, the system will lock up. This is not handled in the patch nor explained in the changelog. > > After this patch we should guarantee a forward progress for the OOM > killer even when the selected victim is sharing memory with a kernel > thread or global init.