All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.cz>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Konstantin Khlebnikov <khlebnikov@openvz.org>,
	Oleg Nesterov <oleg@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Tejun Heo <htejun@gmail.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch] oom: thaw threads if oom killed thread is frozen before deferring
Date: Thu, 29 Sep 2011 13:51:05 +0200	[thread overview]
Message-ID: <20110929115105.GE21113@tiehlicka.suse.cz> (raw)
In-Reply-To: <20110928104445.GB15062@tiehlicka.suse.cz>

On Wed 28-09-11 12:44:45, Michal Hocko wrote:
> On Tue 27-09-11 11:35:04, David Rientjes wrote:
> > On Tue, 27 Sep 2011, Michal Hocko wrote:
> > 
> > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > > index 626303b..c419a7e 100644
> > > --- a/mm/oom_kill.c
> > > +++ b/mm/oom_kill.c
> > > @@ -32,6 +32,7 @@
> > >  #include <linux/mempolicy.h>
> > >  #include <linux/security.h>
> > >  #include <linux/ptrace.h>
> > > +#include <linux/freezer.h>
> > >  
> > >  int sysctl_panic_on_oom;
> > >  int sysctl_oom_kill_allocating_task;
> > > @@ -451,10 +452,15 @@ static int oom_kill_task(struct task_struct *p, struct mem_cgroup *mem)
> > >  				task_pid_nr(q), q->comm);
> > >  			task_unlock(q);
> > >  			force_sig(SIGKILL, q);
> > > +
> > > +			if (frozen(q))
> > > +				thaw_process(q);
> > >  		}
> > >  
> > >  	set_tsk_thread_flag(p, TIF_MEMDIE);
> > >  	force_sig(SIGKILL, p);
> > > +	if (frozen(p))
> > > +		thaw_process(p);
> > >  
> > >  	return 0;
> > >  }
> > 
> > Also needs this...
> > 
> > 
> > oom: thaw threads if oom killed thread is frozen before deferring
> > 
> > If a thread has been oom killed and is frozen, thaw it before returning
> > to the page allocator.  Otherwise, it can stay frozen indefinitely and
> > no memory will be freed.
> 
> OK, I can see the race now:
> oom_kill_task				refrigerator
>   set_tsk_thread_flag(p, TIF_MEMDIE);
>   force_sig(SIGKILL, p);
>   if (frozen(p))
>   	thaw_process(p)
> 					  frozen_process();
> 					  [...]
> 					  if (!frozen(current))
> 					  	break;
> 					  schedule();
> 
> select_bad_process
>   [...]
>   if (test_tsk_thread_flag(p, TIF_MEMDIE))
> 	  return ERR_PTR(-1UL);
> 
> So we either have to make sure that TIF_MEMDIE task is not frozen in
> select_bad_process (your patch) or check for fatal_signal_pending
> in refrigerator before we schedule and break out of the loop. Maybe the
> later one is safer? Rafael?

What about this?
---
>From 2c9d15f19ae9b5e8f2497b41c1718782bc65e1e7 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.cz>
Date: Thu, 29 Sep 2011 13:45:22 +0200
Subject: [PATCH] freezer: Get out of refrigerator if fatal signals are
 pending

We should make sure that the current task doesn't enter refrigerator if
it has fatal signals pending because it should get to the signals
processing as soon as possible.

This closes a possible race when OOM killer selects a task which is
about to enter the fridge but it is not set as frozen yet. This will
lead to a livelock because select_bad_process would skip that task due
to TIF_MEMDIE set for the process but there is no chance for further
process.
oom_kill_task                           refrigerator
  set_tsk_thread_flag(p, TIF_MEMDIE);
  force_sig(SIGKILL, p);
  if (frozen(p))
        thaw_process(p)
                                          frozen_process();
                                          [...]
                                          if (!frozen(current))
                                                break;
                                          schedule();

select_bad_process
  [...]
  if (test_tsk_thread_flag(p, TIF_MEMDIE))
          return ERR_PTR(-1UL);

Signed-off-by: Michal Hocko <mhocko@suse.cz>
---
 kernel/freezer.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/kernel/freezer.c b/kernel/freezer.c
index 7b01de9..74b8434 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -48,6 +48,10 @@ void refrigerator(void)
 	current->flags |= PF_FREEZING;
 
 	for (;;) {
+		if (fatal_signal_pending(current)) {
+			current->flags &= ~PF_FROZEN;
+			break;
+		}
 		set_current_state(TASK_UNINTERRUPTIBLE);
 		if (!frozen(current))
 			break;
-- 
1.7.6.3

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.cz>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Konstantin Khlebnikov <khlebnikov@openvz.org>,
	Oleg Nesterov <oleg@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Tejun Heo <htejun@gmail.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch] oom: thaw threads if oom killed thread is frozen before deferring
Date: Thu, 29 Sep 2011 13:51:05 +0200	[thread overview]
Message-ID: <20110929115105.GE21113@tiehlicka.suse.cz> (raw)
In-Reply-To: <20110928104445.GB15062@tiehlicka.suse.cz>

On Wed 28-09-11 12:44:45, Michal Hocko wrote:
> On Tue 27-09-11 11:35:04, David Rientjes wrote:
> > On Tue, 27 Sep 2011, Michal Hocko wrote:
> > 
> > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > > index 626303b..c419a7e 100644
> > > --- a/mm/oom_kill.c
> > > +++ b/mm/oom_kill.c
> > > @@ -32,6 +32,7 @@
> > >  #include <linux/mempolicy.h>
> > >  #include <linux/security.h>
> > >  #include <linux/ptrace.h>
> > > +#include <linux/freezer.h>
> > >  
> > >  int sysctl_panic_on_oom;
> > >  int sysctl_oom_kill_allocating_task;
> > > @@ -451,10 +452,15 @@ static int oom_kill_task(struct task_struct *p, struct mem_cgroup *mem)
> > >  				task_pid_nr(q), q->comm);
> > >  			task_unlock(q);
> > >  			force_sig(SIGKILL, q);
> > > +
> > > +			if (frozen(q))
> > > +				thaw_process(q);
> > >  		}
> > >  
> > >  	set_tsk_thread_flag(p, TIF_MEMDIE);
> > >  	force_sig(SIGKILL, p);
> > > +	if (frozen(p))
> > > +		thaw_process(p);
> > >  
> > >  	return 0;
> > >  }
> > 
> > Also needs this...
> > 
> > 
> > oom: thaw threads if oom killed thread is frozen before deferring
> > 
> > If a thread has been oom killed and is frozen, thaw it before returning
> > to the page allocator.  Otherwise, it can stay frozen indefinitely and
> > no memory will be freed.
> 
> OK, I can see the race now:
> oom_kill_task				refrigerator
>   set_tsk_thread_flag(p, TIF_MEMDIE);
>   force_sig(SIGKILL, p);
>   if (frozen(p))
>   	thaw_process(p)
> 					  frozen_process();
> 					  [...]
> 					  if (!frozen(current))
> 					  	break;
> 					  schedule();
> 
> select_bad_process
>   [...]
>   if (test_tsk_thread_flag(p, TIF_MEMDIE))
> 	  return ERR_PTR(-1UL);
> 
> So we either have to make sure that TIF_MEMDIE task is not frozen in
> select_bad_process (your patch) or check for fatal_signal_pending
> in refrigerator before we schedule and break out of the loop. Maybe the
> later one is safer? Rafael?

What about this?
---

  reply	other threads:[~2011-09-29 11:51 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-27  8:09 [PATCH 0/2] oom: fix livelock when frozen task is selected Michal Hocko
2011-09-27  6:56 ` [PATCH 1/2] lguest: move process freezing before pending signals check Michal Hocko
2011-10-12  6:55   ` Michal Hocko
2011-10-12  6:55     ` Michal Hocko
2011-10-12 23:57     ` Rusty Russell
2011-10-12 23:57       ` Rusty Russell
2011-10-13  5:48       ` Michal Hocko
2011-10-13  5:48         ` Michal Hocko
2011-09-27  8:01 ` [PATCH 2/2] oom: do not live lock on frozen tasks Michal Hocko
2011-09-27 18:35   ` [patch] oom: thaw threads if oom killed thread is frozen before deferring David Rientjes
2011-09-27 18:35     ` David Rientjes
2011-09-28 10:44     ` Michal Hocko
2011-09-28 10:44       ` Michal Hocko
2011-09-29 11:51       ` Michal Hocko [this message]
2011-09-29 11:51         ` Michal Hocko
2011-09-29 12:05         ` Oleg Nesterov
2011-09-29 12:05           ` Oleg Nesterov
2011-09-29 13:02           ` Michal Hocko
2011-09-29 13:02             ` Michal Hocko
2011-09-29 16:32             ` Michal Hocko
2011-09-29 16:32               ` Michal Hocko
2011-09-29 16:37             ` Oleg Nesterov
2011-09-29 16:37               ` Oleg Nesterov
2011-09-29 18:00               ` Michal Hocko
2011-09-29 18:00                 ` Michal Hocko
2011-09-30  1:51                 ` Tejun Heo
2011-09-30  1:51                   ` Tejun Heo
2011-09-30  7:41                   ` Michal Hocko
2011-09-30  7:41                     ` Michal Hocko
2011-09-30  7:46                     ` Tejun Heo
2011-09-30  7:46                       ` Tejun Heo
2011-09-30  8:04                       ` Michal Hocko
2011-09-30  8:04                         ` Michal Hocko
2011-09-30 15:30                 ` Oleg Nesterov
2011-09-30 15:30                   ` Oleg Nesterov
2011-10-28 22:23   ` [PATCH 2/2] oom: do not live lock on frozen tasks Andrew Morton
2011-10-28 22:23     ` Andrew Morton
2011-10-29  9:01     ` Michal Hocko
2011-10-29  9:01       ` 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=20110929115105.GE21113@tiehlicka.suse.cz \
    --to=mhocko@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=htejun@gmail.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=khlebnikov@openvz.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=oleg@redhat.com \
    --cc=rientjes@google.com \
    --cc=rjw@sisk.pl \
    --cc=rusty@rustcorp.com.au \
    /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.