linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: David Rientjes <rientjes@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	"Luis Claudio R. Goncalves" <lclaudio@uudg.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Nick Piggin <npiggin@suse.de>
Subject: Re: [PATCH 09/12] oom: remove PF_EXITING check completely
Date: Fri, 4 Jun 2010 00:11:45 +0200	[thread overview]
Message-ID: <20100603221145.GB8511@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1006031313040.10856@chino.kir.corp.google.com>

On 06/03, David Rientjes wrote:
>
> On Thu, 3 Jun 2010, Oleg Nesterov wrote:
>
> > On 06/02, David Rientjes wrote:
> > >
> > > On Thu, 3 Jun 2010, KOSAKI Motohiro wrote:
> > >
> > > > Currently, PF_EXITING check is completely broken. because 1) It only
> > > > care main-thread and ignore sub-threads
> > >
> > > Then check the subthreads.
> > >
>
> Did you want to respond to this?

Please explain what you mean. There were already a lot of discussions
about mt issues, I do not know what you have in mind.

> > > It may ignore SIGKILL, but does not ignore fatal_signal_pending() being
> > > true
> >
> > Wrong.
> >
> > Unless the oom victim is exactly the thread which dumps the core,
> > fatal_signal_pending() won't be true for the dumper. Even if the
> > victim and the dumper are from the same group, this thread group
> > already has SIGNAL_GROUP_EXIT. And if they do not belong to the
> > same group, SIGKILL has even less effect.
> >
>
> I'm guessing at the relevancy here because the changelog is extremely
> poorly worded (if I were Andrew I would have no idea how important this
> patch is based on the description other than the alarmist words of "... is
> completely broken)", but if we're concerned about the coredumper not being
> able to find adequate resources to allocate memory from, we can give it
> access to reserves specifically,

I don't think so. If oom-kill wants to kill the task which dumps the
code, it should stop the coredumping and exit.

> we don't need to go killing additional
> tasks which may have their own coredumpers.

Sorry, can't understand.

> That's an alternative solution as well, but I'm disagreeing with the
> approach here because this enforces absolutely no guarantee that the next
> task to be oom killed will be the coredumper, its much more likely that
> we're just going to kill yet another task for the coredump.  That task may
> have a coredumper too.  Who knows.

Again, please explain this to me.

> > > Nacked-by: David Rientjes <rientjes@google.com>
> >
> > Kosaki removes the code which only pretends to work, but it doesn't
> > and leads to problems.
> >
>
> LOL, this code doesn't pretend to work,
> ...
> certain code doesn't do a complete job in certain cases or it can
> introduce a deadlock in situations

OK, agreed. It is not that it never works.

Oleg.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-06-03 22:13 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-03  5:48 [mmotm 0521][PATCH 0/12] various OOM fixes for 2.6.35 KOSAKI Motohiro
2010-06-03  5:49 ` [PATCH 01/12] oom: select_bad_process: check PF_KTHREAD instead of !mm to skip kthreads KOSAKI Motohiro
2010-06-03  5:50 ` [PATCH 02/12] oom: introduce find_lock_task_mm() to fix !mm false positives KOSAKI Motohiro
2010-06-03  6:12   ` Minchan Kim
2010-06-03  6:52     ` KOSAKI Motohiro
2010-06-03  5:51 ` [PATCH 03/12] oom: the points calculation of child processes must use find_lock_task_mm() too KOSAKI Motohiro
2010-06-03  6:20   ` Minchan Kim
2010-06-03  5:52 ` [PATCH 04/12] oom: __oom_kill_task() " KOSAKI Motohiro
2010-06-03  5:53 ` [PATCH 05/12] oom: make oom_unkillable() helper function KOSAKI Motohiro
2010-06-03  6:11 ` [mmotm 0521][PATCH 0/12] various OOM fixes for 2.6.35 Minchan Kim
2010-06-03  6:23 ` [PATCH 06/12] oom: remove warning for in mm-less task __oom_kill_process() KOSAKI Motohiro
2010-06-03  6:31   ` KAMEZAWA Hiroyuki
2010-06-03  6:37   ` David Rientjes
2010-06-03  6:23 ` [PATCH 07/12] oom: Fix child process iteration properly KOSAKI Motohiro
2010-06-03  6:33   ` KAMEZAWA Hiroyuki
2010-06-03  6:24 ` [PATCH 08/12] oom: dump_tasks() use find_lock_task_mm() too KOSAKI Motohiro
2010-06-03  6:34   ` KAMEZAWA Hiroyuki
2010-06-03 15:21   ` Oleg Nesterov
2010-06-03 15:26   ` Oleg Nesterov
2010-06-03 20:12     ` David Rientjes
2010-06-03 22:01       ` Oleg Nesterov
2010-06-03 23:18         ` David Rientjes
2010-06-04 10:54     ` [PATCH 13/12] oom: dump_header() need tasklist_lock KOSAKI Motohiro
2010-06-03  6:25 ` [PATCH 09/12] oom: remove PF_EXITING check completely KOSAKI Motohiro
2010-06-03  6:34   ` David Rientjes
2010-06-03 14:00     ` Oleg Nesterov
2010-06-03 20:26       ` David Rientjes
2010-06-03 22:11         ` Oleg Nesterov [this message]
2010-06-03 23:23           ` David Rientjes
2010-06-04 10:04             ` Oleg Nesterov
2010-06-04 10:54     ` KOSAKI Motohiro
2010-06-03  6:36   ` KAMEZAWA Hiroyuki
2010-06-03  6:26 ` [PATCH 10/12] oom: sacrifice child with highest badness score for parent KOSAKI Motohiro
2010-06-03  6:26 ` [PATCH 11/12] oom: remove special handling for pagefault ooms KOSAKI Motohiro
2010-06-03  6:27 ` [PATCH 12/12] oom: give current access to memory reserves if it has been killed KOSAKI Motohiro
2010-06-08 11:41   ` KOSAKI Motohiro
2010-06-08 18:26     ` David Rientjes
2010-06-08 11:41 ` [mmotm 0521][PATCH 0/12] various OOM fixes for 2.6.35 KOSAKI Motohiro
2010-06-08 11:41 ` KOSAKI Motohiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100603221145.GB8511@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=lclaudio@uudg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).