Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [patch] mm, oom: dump stack of victim when reaping failed
To:     David Rientjes <rientjes@google.com>
Cc:     Michal Hocko <mhocko@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org
References: <alpine.DEB.2.21.2001141519280.200484@chino.kir.corp.google.com>
 <20200115084336.GW19428@dhcp22.suse.cz>
 <9a7cbbf0-4283-f932-e422-84b4fb42a055@I-love.SAKURA.ne.jp>
 <alpine.DEB.2.21.2001151223040.13588@chino.kir.corp.google.com>
From:   Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Message-ID: <84fddb8e-a23b-e970-c8e9-74aa2fe2716d@i-love.sakura.ne.jp>
Date:   Thu, 16 Jan 2020 06:09:57 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2001151223040.13588@chino.kir.corp.google.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 2020/01/16 5:27, David Rientjes wrote:
> I'm 
> currently tracking a stall in oom reaping where the victim doesn't always 
> have a lock held so we don't know where it's at in the kernel; I'm hoping 
> that a stack for the thread group leader will at least shed some light on 
> it.
> 

This change was already proposed at
https://lore.kernel.org/linux-mm/20180320122818.GL23100@dhcp22.suse.cz/ .

And according to that proposal, it is likely i_mmap_lock_write() in dup_mmap()
in copy_process(). We tried to make that lock killable but we gave it up
because nobody knows whether it is safe to do make it killable.