Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4867881imm; Wed, 30 May 2018 13:43:38 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJcuU+6dQqoRmndD3TsWCyTfde2M490aWLwQ4q1H1/J2UIztlvANHYE/FOwF1NDC6jqRg2p X-Received: by 2002:a65:6645:: with SMTP id z5-v6mr3350150pgv.43.1527713018154; Wed, 30 May 2018 13:43:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527713018; cv=none; d=google.com; s=arc-20160816; b=PwUL/UE2fxG4KpU46UfghJ0mFKry5bA06t/l+PA1G+9wsQrc8htbm4dyHYQVYVckLb P1HTlxS9yp3idFiAyrm7QjiChGXlC6grd3U2kKk7JFPRYWotx8Rp9vigINNYBtpKW36i ZBFgiBRRScPu2ztC9RC6AIqgc3o8oDhzciLckKd84chsPVZBdQfKpc2qGH30fb092i5j cQcbrL9xUQjfWXgnHBj24wib1IFjOiSNzAO+c4NwG6MLOAbxJIdVkY+pnRd1XJ6NQuvo 4inKFyki5Y3RIqhs1pH7aYOKLzCg7V8HmSR92mX9YdswAyu5Xf9KDCalU8DGw+yUQFpK TbpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=aae1CRVHuk+XPqdUs5WytcSQHjULTxFRsGREPK/pDxw=; b=Z5aEWM5TWwhZcgW8pxyqGvS+NhL5KynYLLI6CrPWDqIMsHQMz/K5RpCCRCX+fnXNDI YzfC5JGALpdFs+cHdTyrrfGVpzxX75n1iw6Lb6lfIRHxgs1RAE3Y/uQla2NragjvZTx7 2kk1w4NJFEq/dFfMzc93jonwh5mn0hFozsA4L5o9h7X2nC7h3HxujZFfysOKg92nM8C0 sUcYvfrftvlD9I/ol+tJqF56lzK0maBINp2PE+kGZ8KFiKCGM3KGFZLxbYPkaxPWt1A4 4j/i8R4s+60TIckdnLaiQiQa+ip29u5yle2sX5F3zbJIk7aI1XfBFJrJszhwq7+g4iQW NQAA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d9-v6si14348459pli.201.2018.05.30.13.43.24; Wed, 30 May 2018 13:43:38 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932250AbeE3UnA (ORCPT + 99 others); Wed, 30 May 2018 16:43:00 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:48382 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932176AbeE3Um6 (ORCPT ); Wed, 30 May 2018 16:42:58 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.92]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 4FF16E76; Wed, 30 May 2018 20:42:57 +0000 (UTC) Date: Wed, 30 May 2018 13:42:56 -0700 From: Andrew Morton To: ufo19890607 Cc: mhocko@suse.com, rientjes@google.com, kirill.shutemov@linux.intel.com, aarcange@redhat.com, penguin-kernel@I-love.SAKURA.ne.jp, guro@fb.com, yang.s@alibaba-inc.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, yuzhoujian Subject: Re: [PATCH v4] Print the memcg's name when system-wide OOM happened Message-Id: <20180530134256.bbf7a8639571a3f8910b6a05@linux-foundation.org> In-Reply-To: <1526870386-2439-1-git-send-email-ufo19890607@gmail.com> References: <1526870386-2439-1-git-send-email-ufo19890607@gmail.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 21 May 2018 03:39:46 +0100 ufo19890607 wrote: > From: yuzhoujian > > The dump_header does not print the memcg's name when the system > oom happened. So users cannot locate the certain container which > contains the task that has been killed by the oom killer. > > System oom report will print the memcg's name after this patch, > so users can get the memcg's path from the oom report and check > the certain container more quickly. lkp-robot is reporting an oops. > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -433,6 +433,7 @@ static void dump_header(struct oom_control *oc, struct task_struct *p) > if (is_memcg_oom(oc)) > mem_cgroup_print_oom_info(oc->memcg, p); > else { > + mem_cgroup_print_oom_memcg_name(oc->memcg, p); > show_mem(SHOW_MEM_FILTER_NODES, oc->nodemask); > if (is_dump_unreclaim_slabs()) > dump_unreclaimable_slab(); static inline bool is_memcg_oom(struct oom_control *oc) { return oc->memcg != NULL; } So in the mem_cgroup_print_oom_memcg_name() call which this patch adds, oc->memcg is known to be NULL. How can this possibly work?