lkml.org 
[lkml]   [2012]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/9] blkcg: drop unnecessary RCU locking
On Thu, Feb 16, 2012 at 02:37:51PM -0800, Tejun Heo wrote:

[..]
> * queue_lock coverage extended to cover @blkg usage in
> blkio_policy_parse_and_set() and RCU dropped. This means all config
> update callbacks are now called under queue_lock.
>

[..]
> @@ -1041,11 +1034,8 @@ static int blkio_policy_parse_and_set(char *buf, enum blkio_policy_id plid,
> if (!disk || part)
> goto out;
>
> - rcu_read_lock();
> -
> spin_lock_irq(disk->queue->queue_lock);
> blkg = blkg_lookup_create(blkcg, disk->queue, plid, false);
> - spin_unlock_irq(disk->queue->queue_lock);
>

So now in some cases we call blkg_lookup_create() with both queue and rcu
read lock held (cfq_lookup_create_cfqg()) and in this case hold only queue
lock. blkg_lookup_create() calls blkg_lookup() which expects a rcu_read_lock()
to be held and we will be travesing that list without rcu_read_lock()
held. Isn't that a problem? We might be examining a blkg belonging to
a different queue and it might be being freed parallely.

Or blkg destruction in this cgroup is serialized by cgroup_mutex() or
by something else in this policy parse and set path?

Thanks
Vivek


\
 
 \ /
  Last update: 2012-02-17 17:51    [W:0.119 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site