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: Thu, 3 Jun 2010 16:00:08 +0200 [thread overview]
Message-ID: <20100603140008.GA3548@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1006022332320.22441@chino.kir.corp.google.com>
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.
>
> > 2) If user enable core-dump
> > feature, it can makes deadlock because the task during coredump ignore
> > SIGKILL.
> >
>
> 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.
Even if we chose the right thread we can race with
clear_thread_flag(TIF_SIGPENDING), but fatal_signal_pending()
checks signal_pending().
> which gives it access to memory reserves with my patchset
__get_user_pages() already checks fatal_signal_pending(), this
is where the dumper allocates the memory (mostly).
And I am not sure I understand the "access to memory reserves",
the dumper should just stop if oom-kill decides it should die,
it can use a lot more memory if it doesn't stop.
> Nacked-by: David Rientjes <rientjes@google.com>
Kosaki removes the code which only pretends to work, but it doesn't
and leads to problems.
If you think we need this check, imho it is better to make the patch
which adds the "right" code with the nice changelog explaining how
this code works.
Just my opinion, I know very little about oom logic/needs/problems,
you can ignore me.
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>
next prev parent reply other threads:[~2010-06-03 14:01 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 [this message]
2010-06-03 20:26 ` David Rientjes
2010-06-03 22:11 ` Oleg Nesterov
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=20100603140008.GA3548@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).