From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: righi.andrea@gmail.com
Cc: Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Paul Menage <menage@google.com>,
containers@lists.linux-foundation.org, linux-mm@kvack.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -mm] memrlimit: fix task_lock() recursive locking (v2)
Date: Thu, 18 Sep 2008 20:28:25 -0700 [thread overview]
Message-ID: <48D31C59.7050404@linux.vnet.ibm.com> (raw)
In-Reply-To: <48D2CD1D.9040202@gmail.com>
Andrea Righi wrote:
> Since we hold task_lock(), we know that p->mm cannot change and we don't have
> to worry about incrementing mm_users. So, just use p->mm directly and
> check that we've not picked a kernel thread.
>
> Signed-off-by: Andrea Righi <righi.andrea@gmail.com>
> ---
> kernel/cgroup.c | 3 ++-
> mm/memrlimitcgroup.c | 10 ++++------
> 2 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 678a680..03cc925 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -2757,7 +2757,8 @@ void cgroup_fork_callbacks(struct task_struct *child)
> * invoke this routine, since it assigns the mm->owner the first time
> * and does not change it.
> *
> - * The callbacks are invoked with mmap_sem held in read mode.
> + * The callbacks are invoked with task_lock held and mmap_sem held in read
> + * mode.
> */
> void cgroup_mm_owner_callbacks(struct task_struct *old, struct task_struct *new)
> {
> diff --git a/mm/memrlimitcgroup.c b/mm/memrlimitcgroup.c
> index 8ee74f6..b3d20f5 100644
> --- a/mm/memrlimitcgroup.c
> +++ b/mm/memrlimitcgroup.c
> @@ -238,7 +238,7 @@ out:
> }
>
> /*
> - * This callback is called with mmap_sem held
> + * This callback is called with mmap_sem and task_lock held
> */
> static void memrlimit_cgroup_mm_owner_changed(struct cgroup_subsys *ss,
> struct cgroup *old_cgrp,
> @@ -246,9 +246,9 @@ static void memrlimit_cgroup_mm_owner_changed(struct cgroup_subsys *ss,
> struct task_struct *p)
> {
> struct memrlimit_cgroup *memrcg, *old_memrcg;
> - struct mm_struct *mm = get_task_mm(p);
> + struct mm_struct *mm = p->mm;
>
> - BUG_ON(!mm);
> + BUG_ON(!mm || (p->flags & PF_KTHREAD));
>
> /*
> * If we don't have a new cgroup, we just uncharge from the old one.
> @@ -258,7 +258,7 @@ static void memrlimit_cgroup_mm_owner_changed(struct cgroup_subsys *ss,
> memrcg = memrlimit_cgroup_from_cgrp(cgrp);
> if (res_counter_charge(&memrcg->as_res,
> mm->total_vm << PAGE_SHIFT))
> - goto out;
> + return;
> }
>
> if (old_cgrp) {
> @@ -266,8 +266,6 @@ static void memrlimit_cgroup_mm_owner_changed(struct cgroup_subsys *ss,
> res_counter_uncharge(&old_memrcg->as_res,
> mm->total_vm << PAGE_SHIFT);
> }
> -out:
> - mmput(mm);
> }
Seems reasonable
Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
--
Balbir
WARNING: multiple messages have this Message-ID (diff)
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: righi.andrea@gmail.com
Cc: Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Paul Menage <menage@google.com>,
containers@lists.linux-foundation.org, linux-mm@kvack.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -mm] memrlimit: fix task_lock() recursive locking (v2)
Date: Thu, 18 Sep 2008 20:28:25 -0700 [thread overview]
Message-ID: <48D31C59.7050404@linux.vnet.ibm.com> (raw)
In-Reply-To: <48D2CD1D.9040202@gmail.com>
Andrea Righi wrote:
> Since we hold task_lock(), we know that p->mm cannot change and we don't have
> to worry about incrementing mm_users. So, just use p->mm directly and
> check that we've not picked a kernel thread.
>
> Signed-off-by: Andrea Righi <righi.andrea@gmail.com>
> ---
> kernel/cgroup.c | 3 ++-
> mm/memrlimitcgroup.c | 10 ++++------
> 2 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 678a680..03cc925 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -2757,7 +2757,8 @@ void cgroup_fork_callbacks(struct task_struct *child)
> * invoke this routine, since it assigns the mm->owner the first time
> * and does not change it.
> *
> - * The callbacks are invoked with mmap_sem held in read mode.
> + * The callbacks are invoked with task_lock held and mmap_sem held in read
> + * mode.
> */
> void cgroup_mm_owner_callbacks(struct task_struct *old, struct task_struct *new)
> {
> diff --git a/mm/memrlimitcgroup.c b/mm/memrlimitcgroup.c
> index 8ee74f6..b3d20f5 100644
> --- a/mm/memrlimitcgroup.c
> +++ b/mm/memrlimitcgroup.c
> @@ -238,7 +238,7 @@ out:
> }
>
> /*
> - * This callback is called with mmap_sem held
> + * This callback is called with mmap_sem and task_lock held
> */
> static void memrlimit_cgroup_mm_owner_changed(struct cgroup_subsys *ss,
> struct cgroup *old_cgrp,
> @@ -246,9 +246,9 @@ static void memrlimit_cgroup_mm_owner_changed(struct cgroup_subsys *ss,
> struct task_struct *p)
> {
> struct memrlimit_cgroup *memrcg, *old_memrcg;
> - struct mm_struct *mm = get_task_mm(p);
> + struct mm_struct *mm = p->mm;
>
> - BUG_ON(!mm);
> + BUG_ON(!mm || (p->flags & PF_KTHREAD));
>
> /*
> * If we don't have a new cgroup, we just uncharge from the old one.
> @@ -258,7 +258,7 @@ static void memrlimit_cgroup_mm_owner_changed(struct cgroup_subsys *ss,
> memrcg = memrlimit_cgroup_from_cgrp(cgrp);
> if (res_counter_charge(&memrcg->as_res,
> mm->total_vm << PAGE_SHIFT))
> - goto out;
> + return;
> }
>
> if (old_cgrp) {
> @@ -266,8 +266,6 @@ static void memrlimit_cgroup_mm_owner_changed(struct cgroup_subsys *ss,
> res_counter_uncharge(&old_memrcg->as_res,
> mm->total_vm << PAGE_SHIFT);
> }
> -out:
> - mmput(mm);
> }
Seems reasonable
Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
--
Balbir
--
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:[~2008-09-19 3:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-18 21:50 [PATCH -mm] memrlimit: fix task_lock() recursive locking (v2) Andrea Righi
2008-09-18 21:50 ` Andrea Righi
2008-09-19 3:28 ` Balbir Singh [this message]
2008-09-19 3:28 ` Balbir Singh
[not found] ` <48D2CD1D.9040202-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2008-09-19 3:28 ` Balbir Singh
-- strict thread matches above, loose matches on Subject: below --
2008-09-18 21:50 Andrea Righi
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=48D31C59.7050404@linux.vnet.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.linux-foundation.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=menage@google.com \
--cc=righi.andrea@gmail.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.