From: Andrew Morton <akpm@osdl.org>
To: Dave Peterson <dsp@llnl.gov>
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 14:31:09 -0700 [thread overview]
Message-ID: <20060414143109.5d537091.akpm@osdl.org> (raw)
In-Reply-To: <200604141349.02047.dsp@llnl.gov>
Dave Peterson <dsp@llnl.gov> wrote:
>
> Another thing I noticed: oom_kill_task() calls mmput() while holding
> tasklist_lock.
Yes, that'll make my new might_sleep() get upset.
oom_kill_task() doesn't _have_ to run mmput() there - we could propagate
the mm back to the top-level and do the mmput() there.
> Here the calls to get_task_mm() and mmput() appear to
> be unnecessary. We shouldn't need to use any kind of locking or
> reference counting since oom_kill_task() doesn't dereference into the
> mm_struct or require the value of p->mm to stay constant. I believe
> the following (untested) code changes should fix the problem (and
> simplify some other parts of the code). Does this look correct?
But yes, this looks better.
>
> diff -urNp -X /home/dsp/dontdiff linux-2.6.17-rc1/mm/oom_kill.c linux-2.6.17-rc1-fix/mm/oom_kill.c
> --- linux-2.6.17-rc1/mm/oom_kill.c 2006-03-19 21:53:29.000000000 -0800
> +++ linux-2.6.17-rc1-fix/mm/oom_kill.c 2006-04-14 13:22:15.000000000 -0700
> @@ -244,17 +244,15 @@ static void __oom_kill_task(task_t *p, c
> force_sig(SIGKILL, p);
> }
>
> -static struct mm_struct *oom_kill_task(task_t *p, const char *message)
> +static int oom_kill_task(task_t *p, const char *message)
> {
> - struct mm_struct *mm = get_task_mm(p);
> + struct mm_struct *mm;
> task_t * g, * q;
Please put a loud comment in here explaining that `mm' may not be dereferenced.
> - if (!mm)
> - return NULL;
> - if (mm == &init_mm) {
> - mmput(mm);
> - return NULL;
> - }
> + mm = p->mm;
> +
> + if ((mm == NULL) || (mm == &init_mm))
I think the parenthesisation here is going a bit far ;)
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@osdl.org>
To: Dave Peterson <dsp@llnl.gov>
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 14:31:09 -0700 [thread overview]
Message-ID: <20060414143109.5d537091.akpm@osdl.org> (raw)
In-Reply-To: <200604141349.02047.dsp@llnl.gov>
Dave Peterson <dsp@llnl.gov> wrote:
>
> Another thing I noticed: oom_kill_task() calls mmput() while holding
> tasklist_lock.
Yes, that'll make my new might_sleep() get upset.
oom_kill_task() doesn't _have_ to run mmput() there - we could propagate
the mm back to the top-level and do the mmput() there.
> Here the calls to get_task_mm() and mmput() appear to
> be unnecessary. We shouldn't need to use any kind of locking or
> reference counting since oom_kill_task() doesn't dereference into the
> mm_struct or require the value of p->mm to stay constant. I believe
> the following (untested) code changes should fix the problem (and
> simplify some other parts of the code). Does this look correct?
But yes, this looks better.
>
> diff -urNp -X /home/dsp/dontdiff linux-2.6.17-rc1/mm/oom_kill.c linux-2.6.17-rc1-fix/mm/oom_kill.c
> --- linux-2.6.17-rc1/mm/oom_kill.c 2006-03-19 21:53:29.000000000 -0800
> +++ linux-2.6.17-rc1-fix/mm/oom_kill.c 2006-04-14 13:22:15.000000000 -0700
> @@ -244,17 +244,15 @@ static void __oom_kill_task(task_t *p, c
> force_sig(SIGKILL, p);
> }
>
> -static struct mm_struct *oom_kill_task(task_t *p, const char *message)
> +static int oom_kill_task(task_t *p, const char *message)
> {
> - struct mm_struct *mm = get_task_mm(p);
> + struct mm_struct *mm;
> task_t * g, * q;
Please put a loud comment in here explaining that `mm' may not be dereferenced.
> - if (!mm)
> - return NULL;
> - if (mm == &init_mm) {
> - mmput(mm);
> - return NULL;
> - }
> + mm = p->mm;
> +
> + if ((mm == NULL) || (mm == &init_mm))
I think the parenthesisation here is going a bit far ;)
--
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 21:29 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
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 [this message]
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=20060414143109.5d537091.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=dsp@llnl.gov \
--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.