From: Dave Peterson <dsp@llnl.gov>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, riel@surriel.com
Subject: Re: [PATCH 2/2] mm: fix mm_struct reference counting bugs in mm/oom_kill.c
Date: Fri, 14 Apr 2006 12:14:35 -0700 [thread overview]
Message-ID: <200604141214.35806.dsp@llnl.gov> (raw)
In-Reply-To: <20060414002654.76d1a6bc.akpm@osdl.org>
On Friday 14 April 2006 00:26, Andrew Morton wrote:
> task_lock() can be used to pin a task's ->mm. To use task_lock() in
> badness() we'd need to either
>
> a) nest task_lock()s. I don't know if we're doing that anywhere else,
> but the parent->child ordering is a natural one. or
>
> b) take a ref on the parent's mm_struct, drop the parent's task_lock()
> while we walk the children, then do mmput() on the parent's mm outside
> tasklist_lock. This is probably better.
Looking a bit more closely at the code, I see that
select_bad_process() iterates over all tasks, repeatedly calling
badness(). This would complicate option 'b' since the iteration is
done while holding tasklist_lock. An alternative to option 'a' that
avoids nesting task_lock()s would be to define a couple of new
functions that might look something like this:
void mmput_atomic(struct mm_struct *mm)
{
if (atomic_dec_and_test(&mm->mm_users)) {
add mm to a global list of expired mm_structs
}
}
void mmput_atomic_cleanup(void)
{
empty the global list of expired mm_structs and do
cleanup stuff for each one
}
Then you could call mmput_atomic() an arbitrary # of times in places
where sleeping is not permitted, as long as mmput_atomic_cleanup() is
later called in a place where sleeping is permissible. In the case
of the OOM killer code, a call to mmput_atomic_cleanup() could be
added to out_of_memory() in a place where we no longer hold
tasklist_lock. Let me know if you have a preference for either of
these options, or if you have other suggestions.
Thanks,
Dave
WARNING: multiple messages have this Message-ID (diff)
From: Dave Peterson <dsp@llnl.gov>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, riel@surriel.com
Subject: Re: [PATCH 2/2] mm: fix mm_struct reference counting bugs in mm/oom_kill.c
Date: Fri, 14 Apr 2006 12:14:35 -0700 [thread overview]
Message-ID: <200604141214.35806.dsp@llnl.gov> (raw)
In-Reply-To: <20060414002654.76d1a6bc.akpm@osdl.org>
On Friday 14 April 2006 00:26, Andrew Morton wrote:
> task_lock() can be used to pin a task's ->mm. To use task_lock() in
> badness() we'd need to either
>
> a) nest task_lock()s. I don't know if we're doing that anywhere else,
> but the parent->child ordering is a natural one. or
>
> b) take a ref on the parent's mm_struct, drop the parent's task_lock()
> while we walk the children, then do mmput() on the parent's mm outside
> tasklist_lock. This is probably better.
Looking a bit more closely at the code, I see that
select_bad_process() iterates over all tasks, repeatedly calling
badness(). This would complicate option 'b' since the iteration is
done while holding tasklist_lock. An alternative to option 'a' that
avoids nesting task_lock()s would be to define a couple of new
functions that might look something like this:
void mmput_atomic(struct mm_struct *mm)
{
if (atomic_dec_and_test(&mm->mm_users)) {
add mm to a global list of expired mm_structs
}
}
void mmput_atomic_cleanup(void)
{
empty the global list of expired mm_structs and do
cleanup stuff for each one
}
Then you could call mmput_atomic() an arbitrary # of times in places
where sleeping is not permitted, as long as mmput_atomic_cleanup() is
later called in a place where sleeping is permissible. In the case
of the OOM killer code, a call to mmput_atomic_cleanup() could be
added to out_of_memory() in a place where we no longer hold
tasklist_lock. Let me know if you have a preference for either of
these options, or if you have other suggestions.
Thanks,
Dave
--
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:[~2006-04-14 19:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-13 21:52 [PATCH 2/2] mm: fix mm_struct reference counting bugs in mm/oom_kill.c Dave Peterson
2006-04-13 21:52 ` Dave Peterson
2006-04-13 23:24 ` Andrew Morton
2006-04-13 23:24 ` Andrew Morton
2006-04-14 0:44 ` Dave Peterson
2006-04-14 0:44 ` Dave Peterson
2006-04-14 7:26 ` Andrew Morton
2006-04-14 7:26 ` Andrew Morton
2006-04-14 19:14 ` Dave Peterson [this message]
2006-04-14 19:14 ` Dave Peterson
2006-04-14 19:45 ` Andrew Morton
2006-04-14 19:45 ` Andrew Morton
2006-04-14 20:49 ` Dave Peterson
2006-04-14 20:49 ` Dave Peterson
2006-04-14 21:31 ` Andrew Morton
2006-04-14 21:31 ` Andrew Morton
2006-04-14 23:52 ` Dave Peterson
2006-04-14 23:52 ` Dave Peterson
2006-04-15 0:00 ` Dave Peterson
2006-04-15 0:00 ` Dave Peterson
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=200604141214.35806.dsp@llnl.gov \
--to=dsp@llnl.gov \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@surriel.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.