From: Oleg Nesterov <oleg@redhat.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, oss-security@lists.openwall.com,
Solar Designer <solar@openwall.com>,
Kees Cook <kees.cook@canonical.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Neil Horman <nhorman@tuxdriver.com>,
linux-fsdevel@vger.kernel.org, pageexec@freemail.hu,
Brad Spengler <spender@grsecurity.net>,
Eugene Teo <eugene@redhat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-mm <linux-mm@kvack.org>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 4/4] oom: don't ignore rss in nascent mm
Date: Thu, 16 Sep 2010 19:44:33 +0200 [thread overview]
Message-ID: <20100916174433.GA4842@redhat.com> (raw)
In-Reply-To: <20100916145710.3BBA.A69D9226@jp.fujitsu.com>
On 09/16, KOSAKI Motohiro wrote:
>
> ChangeLog
> o since v1
> - Always use thread group leader's ->in_exec_mm.
Confused ;)
> +static unsigned long oom_rss_swap_usage(struct task_struct *p)
> +{
> + struct task_struct *t = p;
> + struct task_struct *leader = p->group_leader;
> + unsigned long points = 0;
> +
> + do {
> + task_lock(t);
> + if (t->mm) {
> + points += get_mm_rss(t->mm);
> + points += get_mm_counter(t->mm, MM_SWAPENTS);
> + task_unlock(t);
> + break;
> + }
> + task_unlock(t);
> + } while_each_thread(p, t);
> +
> + /*
> + * If the process is in execve() processing, we have to concern
> + * about both old and new mm.
> + */
> + task_lock(leader);
> + if (leader->in_exec_mm) {
> + points += get_mm_rss(leader->in_exec_mm);
> + points += get_mm_counter(leader->in_exec_mm, MM_SWAPENTS);
> + }
> + task_unlock(leader);
> +
> + return points;
> +}
This patch relies on fact that we can't race with de_thread() (and btw
the change in de_thread() looks bogus). Then why ->in_exec_mm lives in
task_struct ?
To me, this looks a bit strange. I think we should either do not use
->group_leader to hold ->in_exec_mm like your previous patch did, or
move ->in_exec_mm into signal_struct. The previous 3/4 ensures that
only one thread can set ->in_exec_mm.
And I don't think oom_rss_swap_usage() should replace find_lock_task_mm()
in oom_badness(), I mean something like this:
static unsigned long oom_rss_swap_usage(struct mm_struct *mm)
{
return get_mm_rss(mm) + get_mm_counter(mm, MM_SWAPENTS);
}
unsigned int oom_badness(struct task_struct *p, ...)
{
int points = 0;
if (unlikely(p->signal->in_exec_mm)) {
task_lock(p->group_leader);
if (p->signal->in_exec_mm)
points = oom_rss_swap_usage(p->signal->in_exec_mm);
task_unlock(p->group_leader);
}
p = find_lock_task_mm(p);
if (!p)
return points;
...
}
but this is the matter of taste.
What do you think?
Oleg.
WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, oss-security@lists.openwall.com,
Solar Designer <solar@openwall.com>,
Kees Cook <kees.cook@canonical.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Neil Horman <nhorman@tuxdriver.com>,
linux-fsdevel@vger.kernel.org, pageexec@freemail.hu,
Brad Spengler <spender@grsecurity.net>,
Eugene Teo <eugene@redhat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-mm <linux-mm@kvack.org>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 4/4] oom: don't ignore rss in nascent mm
Date: Thu, 16 Sep 2010 19:44:33 +0200 [thread overview]
Message-ID: <20100916174433.GA4842@redhat.com> (raw)
In-Reply-To: <20100916145710.3BBA.A69D9226@jp.fujitsu.com>
On 09/16, KOSAKI Motohiro wrote:
>
> ChangeLog
> o since v1
> - Always use thread group leader's ->in_exec_mm.
Confused ;)
> +static unsigned long oom_rss_swap_usage(struct task_struct *p)
> +{
> + struct task_struct *t = p;
> + struct task_struct *leader = p->group_leader;
> + unsigned long points = 0;
> +
> + do {
> + task_lock(t);
> + if (t->mm) {
> + points += get_mm_rss(t->mm);
> + points += get_mm_counter(t->mm, MM_SWAPENTS);
> + task_unlock(t);
> + break;
> + }
> + task_unlock(t);
> + } while_each_thread(p, t);
> +
> + /*
> + * If the process is in execve() processing, we have to concern
> + * about both old and new mm.
> + */
> + task_lock(leader);
> + if (leader->in_exec_mm) {
> + points += get_mm_rss(leader->in_exec_mm);
> + points += get_mm_counter(leader->in_exec_mm, MM_SWAPENTS);
> + }
> + task_unlock(leader);
> +
> + return points;
> +}
This patch relies on fact that we can't race with de_thread() (and btw
the change in de_thread() looks bogus). Then why ->in_exec_mm lives in
task_struct ?
To me, this looks a bit strange. I think we should either do not use
->group_leader to hold ->in_exec_mm like your previous patch did, or
move ->in_exec_mm into signal_struct. The previous 3/4 ensures that
only one thread can set ->in_exec_mm.
And I don't think oom_rss_swap_usage() should replace find_lock_task_mm()
in oom_badness(), I mean something like this:
static unsigned long oom_rss_swap_usage(struct mm_struct *mm)
{
return get_mm_rss(mm) + get_mm_counter(mm, MM_SWAPENTS);
}
unsigned int oom_badness(struct task_struct *p, ...)
{
int points = 0;
if (unlikely(p->signal->in_exec_mm)) {
task_lock(p->group_leader);
if (p->signal->in_exec_mm)
points = oom_rss_swap_usage(p->signal->in_exec_mm);
task_unlock(p->group_leader);
}
p = find_lock_task_mm(p);
if (!p)
return points;
...
}
but this is the matter of taste.
What do you think?
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-09-16 17:48 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-16 5:52 [PATCH 0/4] oom fixes for 2.6.36 KOSAKI Motohiro
2010-09-16 5:52 ` KOSAKI Motohiro
2010-09-16 5:55 ` [PATCH 1/4] oom: remove totalpage normalization from oom_badness() KOSAKI Motohiro
2010-09-16 5:55 ` KOSAKI Motohiro
2010-09-16 6:36 ` David Rientjes
2010-09-16 6:36 ` David Rientjes
2010-09-16 6:57 ` KOSAKI Motohiro
2010-09-16 6:57 ` KOSAKI Motohiro
2010-09-16 7:47 ` Pekka Enberg
2010-09-16 7:47 ` Pekka Enberg
2010-09-16 5:55 ` [PATCH 2/4] Revert "oom: deprecate oom_adj tunable" KOSAKI Motohiro
2010-09-16 5:55 ` KOSAKI Motohiro
2010-09-16 5:56 ` [PATCH 3/4] move cred_guard_mutex from task_struct to signal_struct KOSAKI Motohiro
2010-09-16 5:56 ` KOSAKI Motohiro
2010-09-16 5:57 ` [PATCH 4/4] oom: don't ignore rss in nascent mm KOSAKI Motohiro
2010-09-16 5:57 ` KOSAKI Motohiro
2010-09-16 17:44 ` Oleg Nesterov [this message]
2010-09-16 17:44 ` Oleg Nesterov
2010-09-27 2:50 ` KOSAKI Motohiro
2010-09-27 2:50 ` 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=20100916174433.GA4842@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=eugene@redhat.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kees.cook@canonical.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nhorman@tuxdriver.com \
--cc=oss-security@lists.openwall.com \
--cc=pageexec@freemail.hu \
--cc=rientjes@google.com \
--cc=solar@openwall.com \
--cc=spender@grsecurity.net \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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.