* [PATCH] Memory controller use rcu_read_lock() in mem_cgroup_cache_charge()
@ 2007-12-20 9:01 Balbir Singh
2007-12-20 10:21 ` KAMEZAWA Hiroyuki
0 siblings, 1 reply; 2+ messages in thread
From: Balbir Singh @ 2007-12-20 9:01 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Balbir Singh, LKML, Andrew Morton, KAMEZAWA Hiroyuki
Hugh Dickins noticed that we were using rcu_dereference() without
rcu_read_lock() in the cache charging routine. The patch below fixes
this problem
Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
---
mm/memcontrol.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff -puN mm/memcontrol.c~memory-controller-use-rcu-lead-lock mm/memcontrol.c
--- linux-2.6.24-rc5/mm/memcontrol.c~memory-controller-use-rcu-lead-lock 2007-12-19 11:52:44.000000000 +0530
+++ linux-2.6.24-rc5-balbir/mm/memcontrol.c 2007-12-20 14:01:45.000000000 +0530
@@ -717,16 +717,20 @@ int mem_cgroup_charge(struct page *page,
int mem_cgroup_cache_charge(struct page *page, struct mm_struct *mm,
gfp_t gfp_mask)
{
+ int ret = 0;
struct mem_cgroup *mem;
if (!mm)
mm = &init_mm;
+ rcu_read_lock();
mem = rcu_dereference(mm->mem_cgroup);
+ css_get(&mem->css);
+ rcu_read_unlock();
if (mem->control_type == MEM_CGROUP_TYPE_ALL)
- return mem_cgroup_charge_common(page, mm, gfp_mask,
+ ret = mem_cgroup_charge_common(page, mm, gfp_mask,
MEM_CGROUP_CHARGE_TYPE_CACHE);
- else
- return 0;
+ css_put(&mem->css);
+ return ret;
}
/*
_
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] Memory controller use rcu_read_lock() in mem_cgroup_cache_charge()
2007-12-20 9:01 [PATCH] Memory controller use rcu_read_lock() in mem_cgroup_cache_charge() Balbir Singh
@ 2007-12-20 10:21 ` KAMEZAWA Hiroyuki
0 siblings, 0 replies; 2+ messages in thread
From: KAMEZAWA Hiroyuki @ 2007-12-20 10:21 UTC (permalink / raw)
To: Balbir Singh; +Cc: Hugh Dickins, LKML, Andrew Morton
On Thu, 20 Dec 2007 14:31:52 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>
>
> Hugh Dickins noticed that we were using rcu_dereference() without
> rcu_read_lock() in the cache charging routine. The patch below fixes
> this problem
>
> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> ---
>
> mm/memcontrol.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff -puN mm/memcontrol.c~memory-controller-use-rcu-lead-lock mm/memcontrol.c
> --- linux-2.6.24-rc5/mm/memcontrol.c~memory-controller-use-rcu-lead-lock 2007-12-19 11:52:44.000000000 +0530
> +++ linux-2.6.24-rc5-balbir/mm/memcontrol.c 2007-12-20 14:01:45.000000000 +0530
> @@ -717,16 +717,20 @@ int mem_cgroup_charge(struct page *page,
> int mem_cgroup_cache_charge(struct page *page, struct mm_struct *mm,
> gfp_t gfp_mask)
> {
> + int ret = 0;
> struct mem_cgroup *mem;
> if (!mm)
> mm = &init_mm;
>
> + rcu_read_lock();
> mem = rcu_dereference(mm->mem_cgroup);
> + css_get(&mem->css);
> + rcu_read_unlock();
> if (mem->control_type == MEM_CGROUP_TYPE_ALL)
> - return mem_cgroup_charge_common(page, mm, gfp_mask,
> + ret = mem_cgroup_charge_common(page, mm, gfp_mask,
> MEM_CGROUP_CHARGE_TYPE_CACHE);
> - else
> - return 0;
> + css_put(&mem->css);
> + return ret;
> }
>
> /*
> _
Seems reasonable to me.
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Thanks,
-Kame
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2007-12-20 10:19 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-12-20 9:01 [PATCH] Memory controller use rcu_read_lock() in mem_cgroup_cache_charge() Balbir Singh
2007-12-20 10:21 ` KAMEZAWA Hiroyuki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox