From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932968AbbI3NrH (ORCPT ); Wed, 30 Sep 2015 09:47:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44997 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932498AbbI3Nqc (ORCPT ); Wed, 30 Sep 2015 09:46:32 -0400 Date: Wed, 30 Sep 2015 15:43:21 +0200 From: Oleg Nesterov To: David Rientjes Cc: Andrew Morton , Kyle Walker , Michal Hocko , Stanislav Kozina , Tetsuo Handa , linux-kernel@vger.kernel.org Subject: Re: [PATCH -mm 1/3] mm/oom_kill: remove the wrong fatal_signal_pending() Message-ID: <20150930134321.GA32263@redhat.com> References: <20150929141815.GA10952@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/29, David Rientjes wrote: > > On Tue, 29 Sep 2015, Oleg Nesterov wrote: > > > The fatal_signal_pending() was added to suppress unnecessary "sharing > > same memory" message, but it can't 100% help anyway because it can be > > false-negative; SIGKILL can be already dequeued. > > > > And worse, it can be false-positive due to exec or coredump. exec is > > mostly fine, but coredump is not. It is possible that the group leader > > has the pending SIGKILL because its sub-thread originated the coredump, > > in this case we must not skip this process. > > > > We could probably add the additional ->group_exit_task check but this > > pach just removes fatal_signal_pending(), the extra "Kill process" is > > unlikely and doesn't really hurt. > > > > Signed-off-by: Oleg Nesterov > > Acked-by: David Rientjes Thanks! > In addition, I'm really debating whether we need the "sharing same memory" > line or not. In the past, it has been helpful because there is no other > way to determine what the kernel has killed other than to leave an > artifact behind in the kernel log. I can imagine that this could easily > spam the kernel log, though, accompanied by oom killer messages that are > already very verbose. I wouldn't mind if it the printk were removed > entirely. Yes, me too... let me reply to Tetsuo's email. Oleg.