[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1511301407080.10460@chino.kir.corp.google.com>
Date: Mon, 30 Nov 2015 14:08:23 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: "Chenjie (K)" <chenjie6@...wei.com>
cc: Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, David.Woodhouse@...el.com,
zhihui.gao@...wei.com, lizefan@...wei.com, stable@...r.kernel.org
Subject: Re: [PATCH] bugfix oom kill init lead panic
On Mon, 30 Nov 2015, Chenjie (K) wrote:
> My kernel version is 3.10 ,but the 4.3 is the same
> and the newest code is
>
> for_each_process(p) {
> if (!process_shares_mm(p, mm))
> continue;
> if (same_thread_group(p, victim))
> continue;
> if (unlikely(p->flags & PF_KTHREAD))
> continue;
> if (p->signal->oom_score_adj == OOM_SCORE_ADJ_MIN)
> continue;
>
> so this not add the !is_global_init also.
>
> when we vfork (CLONE_VM) a process,the copy_mm
> if (clone_flags & CLONE_VM) {
> atomic_inc(&oldmm->mm_users);
> mm = oldmm;
> goto good_mm;
> }
> use the parent mm.
>
I think it might be a legitimate fix, but if the oom killer is killing pid
9134 in your log then I assume the next call to the oom killer will panic
the system anyway unless there is actually a process using less memory
that can be killed. Would you mind enabling vm.oom_dump_tasks (it should
default to enabled) and post the entire oom killer log?
Powered by blists - more mailing lists