From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by kanga.kvack.org (Postfix) with ESMTP id 7BB156B0038 for ; Mon, 1 Jun 2015 08:10:23 -0400 (EDT) Received: by padjw17 with SMTP id jw17so35775989pad.2 for ; Mon, 01 Jun 2015 05:10:23 -0700 (PDT) Received: from www262.sakura.ne.jp (www262.sakura.ne.jp. [2001:e42:101:1:202:181:97:72]) by mx.google.com with ESMTPS id cr2si21303660pdb.74.2015.06.01.05.10.21 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 01 Jun 2015 05:10:22 -0700 (PDT) Subject: Re: [PATCH] mm/oom: Suppress unnecessary "sharing same memory" message. From: Tetsuo Handa References: <20150529144922.GE22728@dhcp22.suse.cz> <201505300220.GCH51071.FVOOFOLQStJMFH@I-love.SAKURA.ne.jp> <20150601090341.GA7147@dhcp22.suse.cz> <201506011951.DCC81216.tMVQHLFOFFOJSO@I-love.SAKURA.ne.jp> <20150601114349.GE7147@dhcp22.suse.cz> In-Reply-To: <20150601114349.GE7147@dhcp22.suse.cz> Message-Id: <201506012110.GHJ73931.LVFOOMFtHOSFJQ@I-love.SAKURA.ne.jp> Date: Mon, 1 Jun 2015 21:10:18 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mm@kvack.org List-ID: To: mhocko@suse.cz Cc: linux-mm@kvack.org Michal Hocko wrote: > On Mon 01-06-15 19:51:05, Tetsuo Handa wrote: > [...] > > How can all fatal_signal_pending() "struct task_struct" get access to memory > > reserves when only one of fatal_signal_pending() "struct task_struct" has > > TIF_MEMDIE ? > > Because of > /* > * If current has a pending SIGKILL or is exiting, then automatically > * select it. The goal is to allow it to allocate so that it may > * quickly exit and free its memory. > * > * But don't select if current has already released its mm and cleared > * TIF_MEMDIE flag at exit_mm(), otherwise an OOM livelock may occur. > */ > if (current->mm && > (fatal_signal_pending(current) || task_will_free_mem(current))) { > mark_oom_victim(current); > goto out; > } Then, what guarantees that the thread which is between down_write(¤t->mm->mmap_sem) and up_write(¤t->mm->mmap_sem) (or whatever locks which are blocking the OOM victim) calls out_of_memory() ? That thread might be doing !__GFP_FS allocation request. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org