From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E802C3F68F for ; Wed, 15 Jan 2020 08:43:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 473892073A for ; Wed, 15 Jan 2020 08:43:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 473892073A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CFC208E0007; Wed, 15 Jan 2020 03:43:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CAD428E0003; Wed, 15 Jan 2020 03:43:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC3628E0007; Wed, 15 Jan 2020 03:43:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0202.hostedemail.com [216.40.44.202]) by kanga.kvack.org (Postfix) with ESMTP id A74548E0003 for ; Wed, 15 Jan 2020 03:43:39 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 25500181AEF0B for ; Wed, 15 Jan 2020 08:43:39 +0000 (UTC) X-FDA: 76379230158.27.mom48_77268b4b43805 X-HE-Tag: mom48_77268b4b43805 X-Filterd-Recvd-Size: 3668 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Wed, 15 Jan 2020 08:43:38 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id j42so14813259wrj.12 for ; Wed, 15 Jan 2020 00:43:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=S/PNDUAlVVVtYjvRnMN304qOmVqAvWD8J5Xrr48hgz4=; b=YnGXDDwYr4div9RIkNVZHLxdc7v0q+V4BfBcKlopBfWTvz/GVYj0+iz8rNzXXFpDAK HnhKru8/+Y9GqEIz1TLbXx/zeUmPZAhwBB2RZem9rJw0j+UcRtD5tJEcewDpJJrD7FRq RlXbBNpUeyp6svZHDXiFMj/QHexlO2xtHFrxFjbU7hIkGE16f28OHn6LMn1LAoivzO3x jaSmTllcKoVPcmIKd4HcrenswX4QDq4u6OA4IaTiPzvO0/qeTXg1bXFXyRH6iO+FyjW4 yLfqZwJVtD6QaBBcolehnjiOrfz4ZcmKS/ZYob7ELlyP6QZCBmoHSFdSC2L0+PPa5Meg zqmg== X-Gm-Message-State: APjAAAW/Z7O6qV4qt2OKtsq1/2V8wUa9a9X4h0s1ekgpKHtzfyScK2pG MBGN9WFOZUDepEhhp1DBZDQ= X-Google-Smtp-Source: APXvYqwGLRWTLB0nzAWAVz8G3S+ZGQ2cWW5Hfuwg70alRK5byH//hBg1tHkuoYxkj7wUIgg9q1sI3g== X-Received: by 2002:adf:d4ca:: with SMTP id w10mr28545870wrk.53.1579077817600; Wed, 15 Jan 2020 00:43:37 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id t8sm23840123wrp.69.2020.01.15.00.43.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jan 2020 00:43:36 -0800 (PST) Date: Wed, 15 Jan 2020 09:43:36 +0100 From: Michal Hocko To: David Rientjes Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [patch] mm, oom: dump stack of victim when reaping failed Message-ID: <20200115084336.GW19428@dhcp22.suse.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue 14-01-20 15:20:04, David Rientjes wrote: > When a process cannot be oom reaped, for whatever reason, currently the > list of locks that are held is currently dumped to the kernel log. > > Much more interesting is the stack trace of the victim that cannot be > reaped. If the stack trace is dumped, we have the ability to find > related occurrences in the same kernel code and hopefully solve the > issue that is making it wedged. > > Dump the stack trace when a process fails to be oom reaped. Yes, this is really helpful. > Signed-off-by: David Rientjes Acked-by: Michal Hocko Thanks! > --- > mm/oom_kill.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -620,6 +621,7 @@ static void oom_reap_task(struct task_struct *tsk) > > pr_info("oom_reaper: unable to reap pid:%d (%s)\n", > task_pid_nr(tsk), tsk->comm); > + sched_show_task(tsk); > debug_show_all_locks(); > > done: -- Michal Hocko SUSE Labs