Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4808347imm; Mon, 30 Jul 2018 23:55:41 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfxsCFvqMOqB15QGVk2Eu1IuAsFVExG8FNrc7mN50rYljTb2JOG5Vm32Tv/CF9LEhRVz0QM X-Received: by 2002:a65:460e:: with SMTP id v14-v6mr18808899pgq.177.1533020141827; Mon, 30 Jul 2018 23:55:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533020141; cv=none; d=google.com; s=arc-20160816; b=WerGU+3i5pReHcbNVjGUyPGg6+34gUs5+7NYiRC6GzS5H45+vZbYvGhSvDWnTY6WyK /LXnZ2Eq1HwpPJnjkSxIkZwcdn3IUEIo7ALpDg42F+cM8iIb+PxXhPvMGlXVBd+TJ1Xs MsqrLtQ6jxL/D8VwI+0W/B4PMEyecbQ9QbZotRPHgB0KTn+8PSVw+LKiV/ys8KH1ALD3 u9wezDpfqbp/jBpHm4EFm2SijNwZ9+ceah3HgFl1JeDOuuYYXbOvm00ZnOFl76QjDpPp /U0t5wA7j+efQPepzLCS2SyZZqI5VOdAIskN6mJ/UCY52fMkuU2yh5IS3s+ut4LUHpuk MtsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=QFwQxb5gJD/bwzGwVB0SLUjQQBBB1+q5LVp6lbvESRY=; b=N5FTECyliMkv7QaM63S6TrLG68LGIK4P+D5V/lT6BjJCOi6IWFpqiIdIaCw9zyPb4O Mqg3qAW6x9a9uX1JdT7dtw+wbgLbdc/yY9fsCd+3t6xbwn5oaa3GTh4BeAgTs7OGiXOy Ov93RLso26JthZ564ct2NxsYf+/RCNNuO3h8icWtw1DBaR8mBQDsw5G+Qt0L4MTuMj6D Vkk4wakQmv68fb0b7zdxqmNGTszxnwnOvJV7u2wuv5owUVBJtHSEaz0L86Mk5eOmcAn5 /GbY0UTSdFt2Xeb/5yLU4cfKHFtTy69A5Qb7KHH35zRHlSWJiYC3uIM8Eumfnpq62ZN6 RU1w== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t16-v6si12247486pga.442.2018.07.30.23.55.27; Mon, 30 Jul 2018 23:55:41 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728918AbeGaId1 (ORCPT + 99 others); Tue, 31 Jul 2018 04:33:27 -0400 Received: from mx2.suse.de ([195.135.220.15]:56596 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726591AbeGaId1 (ORCPT ); Tue, 31 Jul 2018 04:33:27 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 807CEAD11; Tue, 31 Jul 2018 06:54:37 +0000 (UTC) Date: Tue, 31 Jul 2018 08:54:34 +0200 From: Michal Hocko To: David Rientjes , yuzhoujian Cc: kernel test robot , Stephen Rothwell , "Kirill A. Shutemov" , Andrea Arcangeli , Tetsuo Handa , Roman Gushchin , Yang Shi , Andrew Morton , LKML , lkp@01.org Subject: Re: [LKP] [mm, oom] c1e4c54f9c: BUG:KASAN:null-ptr-deref_in_d Message-ID: <20180731065434.GB4557@dhcp22.suse.cz> References: <20180730090320.GD30690@shao2-debian> <20180730095635.GI24267@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 30-07-18 19:05:50, David Rientjes wrote: > On Mon, 30 Jul 2018, Michal Hocko wrote: > > > On Mon 30-07-18 17:03:20, kernel test robot wrote: > > [...] > > > [ 9.034310] BUG: KASAN: null-ptr-deref in dump_header+0x10c/0x448 > > > > Could you faddr2line on the offset please? > > > > It's possible that p is NULL when calling dump_header(). In this case we > do not want to print any line concerning a victim because no oom kill has > occurred. You are right. I have missed those. > This code shouldn't be part of dump_header(), which is called from > multiple contexts even when an oom kill has not occurred, and is > ratelimited. The single line output should be the canonical way that > userspace parses the log for oom victims, we can't ratelimit it. > > The following would be a fix patch, but it will be broken if the cgroup > aware oom killer is removed from -mm so that the oom_group stuff can be > merged. cgroup aware oom killer is going to be replaced by a new implementation IIUC so the fix should be based on the yuzhoujian patch. Ideally to be resubmitted. I would just suggest adding it into a function dump_oom_summary(struct oom_control *oc, struct task_struct *p) yuzhoujian could you take care of that please? > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -438,14 +438,6 @@ static void dump_header(struct oom_control *oc, struct task_struct *p) > > dump_stack(); > > - /* one line summary of the oom killer context. */ > - pr_info("oom-kill:constraint=%s,nodemask=%*pbl", > - oom_constraint_text[oc->constraint], > - nodemask_pr_args(oc->nodemask)); > - cpuset_print_current_mems_allowed(); > - mem_cgroup_print_oom_context(oc->memcg, p); > - pr_cont(",task=%s,pid=%d,uid=%d\n", p->comm, p->pid, > - from_kuid(&init_user_ns, task_uid(p))); > if (is_memcg_oom(oc)) > mem_cgroup_print_oom_meminfo(oc->memcg); > else { > @@ -836,7 +828,8 @@ static bool task_will_free_mem(struct task_struct *task) > return ret; > } > > -static void __oom_kill_process(struct task_struct *victim) > +static void __oom_kill_process(struct task_struct *victim, > + struct oom_control *oc) > { > struct task_struct *p; > struct mm_struct *mm; > @@ -883,6 +876,18 @@ static void __oom_kill_process(struct task_struct *victim) > K(get_mm_counter(victim->mm, MM_ANONPAGES)), > K(get_mm_counter(victim->mm, MM_FILEPAGES)), > K(get_mm_counter(victim->mm, MM_SHMEMPAGES))); > + > + if (oc) { > + /* One line summary for non-group oom kills */ > + pr_info("oom-kill: constraint=%s, nodemask=%*pbl", > + oom_constraint_text[oc->constraint], > + nodemask_pr_args(oc->nodemask)); > + cpuset_print_current_mems_allowed(); > + mem_cgroup_print_oom_context(oc->memcg, victim); > + pr_cont(", task=%s, pid=%d, uid=%d\n", > + victim->comm, victim->pid, > + from_kuid(&init_user_ns, task_uid(victim))); > + } > task_unlock(victim); > > /* > @@ -986,13 +991,13 @@ static void oom_kill_process(struct oom_control *oc, const char *message) > } > read_unlock(&tasklist_lock); > > - __oom_kill_process(victim); > + __oom_kill_process(victim, oc); > } > > static int oom_kill_memcg_member(struct task_struct *task, void *unused) > { > get_task_struct(task); > - __oom_kill_process(task); > + __oom_kill_process(task, NULL); > return 0; > } > > @@ -1020,7 +1025,7 @@ static bool oom_kill_memcg_victim(struct oom_control *oc) > oc->chosen_task == INFLIGHT_VICTIM) > goto out; > > - __oom_kill_process(oc->chosen_task); > + __oom_kill_process(oc->chosen_task, oc); > } > > out: -- Michal Hocko SUSE Labs