All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	Kyle Walker <kwalker@redhat.com>,
	Stanislav Kozina <skozina@redhat.com>,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm v2 1/3] mm/oom_kill: remove the wrong fatal_signal_pending() check in oom_kill_process()
Date: Thu, 1 Oct 2015 17:41:15 +0200	[thread overview]
Message-ID: <20151001154115.GA10342@redhat.com> (raw)
In-Reply-To: <20151001152739.GJ24077@dhcp22.suse.cz>

On 10/01, Michal Hocko wrote:
>
> On Thu 01-10-15 17:00:10, Oleg Nesterov wrote:
> > On 10/01, Michal Hocko wrote:
> > >
> > > On Wed 30-09-15 20:24:05, Oleg Nesterov wrote:
> > > [...]
> > > > 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.
> > >
> > > I do not understand this. If the group leader has SIGKILL pending it
> > > will die anyway regardless whether we send another sigkill or not, no?
> >
> > Yes it will die, but only after the coredump is finished.
> >
> > Suppose we have a thread group with the group leader P and another
> > thread T. If T starts the coredump, it sends SIGKILL to P and waits
> > until it parks in exit_mm(). Then T actually dumps the core which may
> > need more memory, a lot of time, etc.
> >
> > We need to kill this process. Yes, P is already killed and it sleeps
> > in TASK_UNINTERRUPTIBLE so this thread does not need SIGKILL. But
> > do_send_sig_info(P) will also find T and kill it too to make
> > dump_interrupted() == T.
>
> I am still utterly confused :( Where do we kill T if it is not in the
> same thread group with P?

But it is in the same thread group?

Oleg.


  reply	other threads:[~2015-10-01 15:44 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-29 14:17 [PATCH -mm 0/3] mm/oom_kill: ensure we actually kill all tasks sharing the same mm Oleg Nesterov
2015-09-29 14:18 ` [PATCH -mm 1/3] mm/oom_kill: remove the wrong fatal_signal_pending() Oleg Nesterov
2015-09-29 22:36   ` David Rientjes
2015-09-30  1:42     ` Tetsuo Handa
2015-09-30 13:47       ` Oleg Nesterov
2015-09-30 15:20         ` [PATCH -mm 1/3] mm/oom_kill: remove the wrongfatal_signal_pending() Tetsuo Handa
2015-09-30 13:43     ` [PATCH -mm 1/3] mm/oom_kill: remove the wrong fatal_signal_pending() Oleg Nesterov
2015-09-29 14:18 ` [PATCH -mm 2/3] mm/oom_kill: cleanup the "kill sharing same memory" Oleg Nesterov
2015-09-29 22:39   ` David Rientjes
2015-09-30 13:49     ` Oleg Nesterov
2015-09-29 14:18 ` [PATCH -mm 3/3] mm/oom_kill: fix the wrong task->mm == mm checks in Oleg Nesterov
2015-09-29 22:41   ` David Rientjes
2015-09-30 13:50     ` Oleg Nesterov
2015-09-30  2:16   ` Tetsuo Handa
2015-09-30 13:59     ` Oleg Nesterov
2015-09-30 18:23 ` [PATCH -mm v2 0/3] mm/oom_kill: ensure we actually kill all tasks sharing the same mm Oleg Nesterov
2015-09-30 18:24   ` [PATCH -mm v2 1/3] mm/oom_kill: remove the wrong fatal_signal_pending() check in oom_kill_process() Oleg Nesterov
2015-09-30 21:14     ` David Rientjes
2015-10-01 10:52       ` [PATCH -mm v2 1/3] mm/oom_kill: remove the wrong fatal_signal_pending()check " Tetsuo Handa
2015-10-01 12:49     ` [PATCH -mm v2 1/3] mm/oom_kill: remove the wrong fatal_signal_pending() check " Michal Hocko
2015-10-01 15:00       ` Oleg Nesterov
2015-10-01 15:27         ` Michal Hocko
2015-10-01 15:41           ` Oleg Nesterov [this message]
2015-10-01 16:19             ` Michal Hocko
2015-10-01 17:53               ` Oleg Nesterov
2015-10-02 11:32                 ` Tetsuo Handa
2015-10-02 12:11                   ` Michal Hocko
2015-10-02 12:33                     ` Tetsuo Handa
2015-10-02 13:32                       ` Michal Hocko
2015-10-02 13:57                         ` Oleg Nesterov
2015-10-02 14:24                           ` Michal Hocko
2015-10-02 14:07                         ` Tetsuo Handa
2015-10-02 14:15                           ` Oleg Nesterov
2015-10-02 13:52                   ` Oleg Nesterov
2015-10-02 14:36                     ` Tetsuo Handa
2015-09-30 18:24   ` [PATCH -mm v2 2/3] mm/oom_kill: cleanup the "kill sharing same memory" loop Oleg Nesterov
2015-09-30 21:15     ` David Rientjes
2015-10-01 12:50     ` Michal Hocko
2015-09-30 18:24   ` [PATCH -mm v2 3/3] mm/oom_kill: fix the wrong task->mm == mm checks in oom_kill_process() Oleg Nesterov
2015-09-30 21:15     ` David Rientjes
2015-10-01 12:56     ` Michal Hocko
2015-10-01 22:24     ` Andrew Morton

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=20151001154115.GA10342@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=kwalker@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=rientjes@google.com \
    --cc=skozina@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.