All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: mhocko@kernel.org
Cc: linux-mm@kvack.org, rientjes@google.com, oleg@redhat.com,
	vdavydov@parallels.com, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/10] mm, oom: hide mm which is shared with kthread or global init
Date: Thu, 16 Jun 2016 22:15:00 +0900	[thread overview]
Message-ID: <201606162215.IIE64528.FFFLHOJQtSOOVM@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <20160609154156.GG24777@dhcp22.suse.cz>

Michal Hocko wrote:
> On Fri 10-06-16 00:15:18, Tetsuo Handa wrote:
> [...]
> > Nobody will set MMF_OOM_REAPED flag if can_oom_reap == true on
> > CONFIG_MMU=n kernel. If a TIF_MEMDIE thread in CONFIG_MMU=n kernel
> > is blocked before exit_oom_victim() in exit_mm() from do_exit() is
> > called, the system will lock up. This is not handled in the patch
> > nor explained in the changelog.
> 
> I have made it clear several times that !CONFIG_MMU is not a target
> of this patch series nor other OOM changes because I am not convinced
> issues which we are trying to solve are real on those platforms. I
> am not really sure what you are trying to achieve now with these
> !CONFIG_MMU remarks but if you see _real_ regressions for those
> configurations please describe them. This generic statements when
> CONFIG_MMU implications are put into !CONFIG_MMU context are not really
> useful. If there are possible OOM killer deadlocks without this series
> then adding these patches shouldn't make them worse.
> 
> E.g. this particular patch is basically a noop for !CONFIG_MMU because
> use_mm() is MMU specific. It is also highly improbable that a task would
> share mm with init...

But this is not safe for CONFIG_MMU=y kernels as well.
can_oom_reap == false means that oom_reap_task() will not be called.
It is possible that the TIF_MEMDIE thread falls into

   atomic_read(&task->signal->oom_victims) > 0 && find_lock_task_mm(task) == NULL

situation. We are still risking OOM livelock. We must somehow clear (or ignore)
TIF_MEMDIE even if oom_reap_task() is not called.

Can't we apply http://lkml.kernel.org/r/201606102323.BCC73478.FtOJHFQMSVFLOO@I-love.SAKURA.ne.jp now?

WARNING: multiple messages have this Message-ID (diff)
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: mhocko@kernel.org
Cc: linux-mm@kvack.org, rientjes@google.com, oleg@redhat.com,
	vdavydov@parallels.com, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/10] mm, oom: hide mm which is shared with kthread or global init
Date: Thu, 16 Jun 2016 22:15:00 +0900	[thread overview]
Message-ID: <201606162215.IIE64528.FFFLHOJQtSOOVM@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <20160609154156.GG24777@dhcp22.suse.cz>

Michal Hocko wrote:
> On Fri 10-06-16 00:15:18, Tetsuo Handa wrote:
> [...]
> > Nobody will set MMF_OOM_REAPED flag if can_oom_reap == true on
> > CONFIG_MMU=n kernel. If a TIF_MEMDIE thread in CONFIG_MMU=n kernel
> > is blocked before exit_oom_victim() in exit_mm() from do_exit() is
> > called, the system will lock up. This is not handled in the patch
> > nor explained in the changelog.
> 
> I have made it clear several times that !CONFIG_MMU is not a target
> of this patch series nor other OOM changes because I am not convinced
> issues which we are trying to solve are real on those platforms. I
> am not really sure what you are trying to achieve now with these
> !CONFIG_MMU remarks but if you see _real_ regressions for those
> configurations please describe them. This generic statements when
> CONFIG_MMU implications are put into !CONFIG_MMU context are not really
> useful. If there are possible OOM killer deadlocks without this series
> then adding these patches shouldn't make them worse.
> 
> E.g. this particular patch is basically a noop for !CONFIG_MMU because
> use_mm() is MMU specific. It is also highly improbable that a task would
> share mm with init...

But this is not safe for CONFIG_MMU=y kernels as well.
can_oom_reap == false means that oom_reap_task() will not be called.
It is possible that the TIF_MEMDIE thread falls into

   atomic_read(&task->signal->oom_victims) > 0 && find_lock_task_mm(task) == NULL

situation. We are still risking OOM livelock. We must somehow clear (or ignore)
TIF_MEMDIE even if oom_reap_task() is not called.

Can't we apply http://lkml.kernel.org/r/201606102323.BCC73478.FtOJHFQMSVFLOO@I-love.SAKURA.ne.jp now?

--
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:[~2016-06-16 13:15 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-09 11:52 [PATCH 0/10 -v4] Handle oom bypass more gracefully Michal Hocko
2016-06-09 11:52 ` Michal Hocko
2016-06-09 11:52 ` [PATCH 01/10] proc, oom: drop bogus task_lock and mm check Michal Hocko
2016-06-09 11:52   ` Michal Hocko
2016-06-09 11:52 ` [PATCH 02/10] proc, oom: drop bogus sighand lock Michal Hocko
2016-06-09 11:52   ` Michal Hocko
2016-06-09 11:52 ` [PATCH 03/10] proc, oom_adj: extract oom_score_adj setting into a helper Michal Hocko
2016-06-09 11:52   ` Michal Hocko
2016-06-09 11:52 ` [PATCH 04/10] mm, oom_adj: make sure processes sharing mm have same view of oom_score_adj Michal Hocko
2016-06-09 11:52   ` Michal Hocko
2016-06-15 15:03   ` Oleg Nesterov
2016-06-15 15:03     ` Oleg Nesterov
2016-06-09 11:52 ` [PATCH 05/10] mm, oom: skip vforked tasks from being selected Michal Hocko
2016-06-09 11:52   ` Michal Hocko
2016-06-15 14:51   ` Oleg Nesterov
2016-06-15 14:51     ` Oleg Nesterov
2016-06-16  6:24     ` Michal Hocko
2016-06-16  6:24       ` Michal Hocko
2016-06-09 11:52 ` [PATCH 06/10] mm, oom: kill all tasks sharing the mm Michal Hocko
2016-06-09 11:52   ` Michal Hocko
2016-06-09 11:52 ` [PATCH 07/10] mm, oom: fortify task_will_free_mem Michal Hocko
2016-06-09 11:52   ` Michal Hocko
2016-06-09 13:18   ` Tetsuo Handa
2016-06-09 13:18     ` Tetsuo Handa
2016-06-09 14:20     ` Michal Hocko
2016-06-09 14:20       ` Michal Hocko
2016-06-11  8:10       ` Tetsuo Handa
2016-06-11  8:10         ` Tetsuo Handa
2016-06-13 11:27         ` Michal Hocko
2016-06-13 11:27           ` Michal Hocko
2016-06-16 12:54           ` Tetsuo Handa
2016-06-16 12:54             ` Tetsuo Handa
2016-06-16 14:29             ` Michal Hocko
2016-06-16 14:29               ` Michal Hocko
2016-06-16 15:40               ` Tetsuo Handa
2016-06-16 15:40                 ` Tetsuo Handa
2016-06-16 15:53                 ` Michal Hocko
2016-06-16 15:53                   ` Michal Hocko
2016-06-17 11:38                   ` Tetsuo Handa
2016-06-17 11:38                     ` Tetsuo Handa
2016-06-17 12:26                     ` Michal Hocko
2016-06-17 12:26                       ` Michal Hocko
2016-06-17 13:12                       ` Tetsuo Handa
2016-06-17 13:12                         ` Tetsuo Handa
2016-06-17 13:29                         ` Michal Hocko
2016-06-17 13:29                           ` Michal Hocko
2016-06-09 11:52 ` [PATCH 08/10] mm, oom: task_will_free_mem should skip oom_reaped tasks Michal Hocko
2016-06-09 11:52   ` Michal Hocko
2016-06-17 11:35   ` Tetsuo Handa
2016-06-17 11:35     ` Tetsuo Handa
2016-06-17 12:56     ` Michal Hocko
2016-06-17 12:56       ` Michal Hocko
2016-06-09 11:52 ` [PATCH 09/10] mm, oom_reaper: do not attempt to reap a task more than twice Michal Hocko
2016-06-09 11:52   ` Michal Hocko
2016-06-15 14:48   ` Oleg Nesterov
2016-06-15 14:48     ` Oleg Nesterov
2016-06-16  6:28     ` Michal Hocko
2016-06-16  6:28       ` Michal Hocko
2016-06-09 11:52 ` [PATCH 10/10] mm, oom: hide mm which is shared with kthread or global init Michal Hocko
2016-06-09 11:52   ` Michal Hocko
2016-06-09 15:15   ` Tetsuo Handa
2016-06-09 15:15     ` Tetsuo Handa
2016-06-09 15:41     ` Michal Hocko
2016-06-09 15:41       ` Michal Hocko
2016-06-16 13:15       ` Tetsuo Handa [this message]
2016-06-16 13:15         ` Tetsuo Handa
2016-06-16 13:36         ` Tetsuo Handa
2016-06-16 13:36           ` Tetsuo Handa
2016-06-15 14:37   ` Oleg Nesterov
2016-06-15 14:37     ` Oleg Nesterov
2016-06-16  6:31     ` Michal Hocko
2016-06-16  6:31       ` Michal Hocko
2016-06-13 11:23 ` [PATCH 0/10 -v4] Handle oom bypass more gracefully Michal Hocko
2016-06-13 11:23   ` Michal Hocko
2016-06-13 14:13   ` Michal Hocko
2016-06-13 14:13     ` Michal Hocko
2016-06-14 20:17     ` Oleg Nesterov
2016-06-14 20:17       ` Oleg Nesterov
2016-06-14 20:44       ` Oleg Nesterov
2016-06-14 20:44         ` Oleg Nesterov
2016-06-16  6:33       ` Michal Hocko
2016-06-16  6:33         ` Michal Hocko
2016-06-15 15:09 ` Oleg Nesterov
2016-06-15 15:09   ` Oleg Nesterov
2016-06-16  6:34   ` Michal Hocko
2016-06-16  6:34     ` Michal Hocko
2016-06-20 12:43 [PATCH 0/10 -v5] " Michal Hocko
2016-06-20 12:43 ` [PATCH 10/10] mm, oom: hide mm which is shared with kthread or global init Michal Hocko
2016-06-20 12:43   ` Michal Hocko
2016-07-19 12:05   ` Michal Hocko
2016-07-19 12:05     ` Michal Hocko
2016-07-19 23:27     ` Andrew Morton
2016-07-19 23:27       ` Andrew Morton
2016-07-20  6:29       ` Michal Hocko
2016-07-20  6:29         ` Michal Hocko

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=201606162215.IIE64528.FFFLHOJQtSOOVM@I-love.SAKURA.ne.jp \
    --to=penguin-kernel@i-love.sakura.ne.jp \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=oleg@redhat.com \
    --cc=rientjes@google.com \
    --cc=vdavydov@parallels.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.