From: Michal Hocko <mhocko@suse.cz>
To: Oleg Nesterov <oleg@redhat.com>
Cc: David Rientjes <rientjes@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Konstantin Khlebnikov <khlebnikov@openvz.org>,
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 18:32:42 +0200 [thread overview]
Message-ID: <20110929163242.GA25076@tiehlicka.suse.cz> (raw)
In-Reply-To: <20110929130204.GG21113@tiehlicka.suse.cz>
On Thu 29-09-11 15:02:04, Michal Hocko wrote:
[...]
> From 3c6c4b4f1a21c34ea1db76b765ce671ca97d9c3e 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. Thaw the process if it is either
> freezing or still frozen to prevent from races with thaw_process.
>
> 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);
>
> Let's skip try_to_freeze in get_signal_to_deliver if fatal signals are
> pending to make sure that we will not somebody will keep us looping
> between refrigerator and get_signal_to_deliver for ever.
I have just read through the description again. I have rewritten it
several times and this is the messed up result. Sorry about that.
The endless loop is not possible as we will handle the fatal signal
after we get back from try_to_freeze and die.
It should read:
"
Let's skip try_to_freeze in get_signal_to_deliver if fatal signals are
pending to make sure that we will not get back to refrigerator again
just to get back immediately.
"
>
> Signed-off-by: Michal Hocko <mhocko@suse.cz>
> ---
> kernel/freezer.c | 5 +++++
> kernel/signal.c | 4 +++-
> 2 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/freezer.c b/kernel/freezer.c
> index 7b01de9..0531661 100644
> --- a/kernel/freezer.c
> +++ b/kernel/freezer.c
> @@ -48,6 +48,11 @@ void refrigerator(void)
> current->flags |= PF_FREEZING;
>
> for (;;) {
> + if (fatal_signal_pending(current)) {
> + if (freezing(current) || frozen(current))
> + thaw_process(current);
> + break;
> + }
> set_current_state(TASK_UNINTERRUPTIBLE);
> if (!frozen(current))
> break;
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 291c970..bc97a6a 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -2147,8 +2147,10 @@ relock:
> * While in TASK_STOPPED, we were considered "frozen enough".
> * Now that we woke up, it's crucial if we're supposed to be
> * frozen that we freeze now before running anything substantial.
> + * Let's ignore the freezing request if we are about to die anyway.
> */
> - try_to_freeze();
> + if (!fatal_signal_pending(curret))
> + try_to_freeze();
>
> spin_lock_irq(&sighand->siglock);
> /*
> --
> 1.7.6.3
>
> --
> Michal Hocko
> SUSE Labs
> SUSE LINUX s.r.o.
> Lihovarska 1060/12
> 190 00 Praha 9
> Czech Republic
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-09-29 16:32 UTC|newest]
Thread overview: 21+ 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 23:57 ` Rusty Russell
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-28 10:44 ` Michal Hocko
2011-09-29 11:51 ` Michal Hocko
2011-09-29 12:05 ` Oleg Nesterov
2011-09-29 13:02 ` Michal Hocko
2011-09-29 16:32 ` Michal Hocko [this message]
2011-09-29 16:37 ` Oleg Nesterov
2011-09-29 18:00 ` Michal Hocko
2011-09-30 1:51 ` Tejun Heo
2011-09-30 7:41 ` Michal Hocko
2011-09-30 7:46 ` Tejun Heo
2011-09-30 8:04 ` Michal Hocko
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-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=20110929163242.GA25076@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox