Messages in this thread | | | Date | Fri, 26 Feb 2010 00:36:15 +0900 | Subject | Re: [PATCH 1/2] memcg: dirty pages accounting and limiting infrastructure | From | Minchan Kim <> |
| |
Hi
On Tue, Feb 23, 2010 at 8:58 PM, Andrea Righi <arighi@develer.com> wrote: > On Mon, Feb 22, 2010 at 01:07:32PM -0500, Vivek Goyal wrote: >> > > > +unsigned long mem_cgroup_dirty_bytes(void) >> > > > +{ >> > > > + struct mem_cgroup *memcg; >> > > > + unsigned long dirty_bytes; >> > > > + >> > > > + if (mem_cgroup_disabled()) >> > > > + return vm_dirty_bytes; >> > > > + >> > > > + rcu_read_lock(); >> > > > + memcg = mem_cgroup_from_task(current); >> > > > + if (memcg == NULL) >> > > > + dirty_bytes = vm_dirty_bytes; >> > > > + else >> > > > + dirty_bytes = get_dirty_bytes(memcg); >> > > > + rcu_read_unlock(); >> > > >> > > The rcu_read_lock() isn't protecting anything here. >> > >> > Right! >> >> Are we not protecting "memcg" pointer using rcu here? > > Vivek, you are right: > > mem_cgroup_from_task() -> task_subsys_state() -> rcu_dereference() > > So, this *must* be RCU protected.
So, Doesn't mem_cgroup_from_task in mem_cgroup_can_attach need RCU, too?
-- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |