[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B29C834.8090407@cn.fujitsu.com>
Date: Thu, 17 Dec 2009 13:57:08 +0800
From: Li Zefan <lizf@...fujitsu.com>
To: Vivek Goyal <vgoyal@...hat.com>
CC: Gui Jianfeng <guijianfeng@...fujitsu.com>,
Jens Axboe <jens.axboe@...cle.com>,
Corrado Zoccolo <czoccolo@...il.com>,
linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cfq: Remove useless css reference get
于 2009年12月17日 00:39, Vivek Goyal 写道:
> On Wed, Dec 16, 2009 at 04:38:43PM +0800, Gui Jianfeng wrote:
>> There's no need to take css reference here, for the caller
>> has already called rcu_read_lock() to prevent cgroup from
>> being removed.
>>
>> Signed-off-by: Gui Jianfeng <guijianfeng@...fujitsu.com>
>> Reviewed-by: Li Zefan <lizf@...fujitsu.com>
>
> Hi Gui,
>
> How would an rcu lock protect against the possibility that blkiocg_destroy()
> has not already been called on another cpu? rcu lock will make sure that
> cgroup and blkio_cgroup object should still be around as long as I am
> holding rcu lock but will not protect against deletion path being executed
> on another cpu? So I don't want to end up in following situation.
>
> cpu1 cpu2
>
> rcu_read_lock()
> blkiocg_destroy()
>
> blkiocg_add_blkio_group()
> rcu_read_unlock()
>
> I don't want to add blkg object on a potentially dead blkio_cgroup object
> which will go away. Does this protection is provided by generic cgroup
> code where blkiocg_destroy() will not be called if I have got cgroup
> pointer under rcu lock?
>
> Currently we are deriving cgroup information from task context so task is
> still inside cgroup, so cgroup can't be deleted anyway. What if I was
> deriving cgroup information from bio, will taking css object reference be
> necessary in that case or just cgroup pointer under rcu lock is sufficient
> to preclude the race against cgroup deletion path?
>
We pass a cgroup ptr to cfq_find_alloc_cfqg(), which means the cgroup is
valid. As long as it's safe to access the cgroup, it's safe to access the
corresponding blkio_cgroup.
But if you still want blkio_cgroup to be valid after dropping rcu_read_lock
(or cgroup_mutex), you need to call css_get() first. Note you don't need
to call css_tryget(). css_tryget() is only needed in mem_cgroup, because
mem_cgroup is a bit special, in that a mem_cgroup can remain valid after
a cgroup is destroyed.
If a user tries to rmdir a cgroup when its css refcnt > 0, EBUSY will be
returned.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists