lkml.org 
[lkml]   [2011]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 10/13] block, cfq: unlink cfq_io_context's immediately
Hello, Vivek.

On Wed, Oct 26, 2011 at 04:38:46PM -0400, Vivek Goyal wrote:
> So the only reason that cic needs to be rcu protected because in
> cfq_cic_lookup() we can access ioc->ioc_data which can point to a
> cic which is not ours and we are not holding queue lock for that and
> we can't access cic->q ?

About right but to be more exact.

* Indexes from ioc are protected by ioc->lock - both the radix tree
and hint. Both are RCU managed.

* cic structures themselves are protected by cic->q->queue_lock and
RCU managed.

* Additions and removals are done holding both ioc and q locks.

* Lookup is performed with RCU read locked and q->queue_lock held.
Indexes and cic's themselves are RCU protected so can be traversed
and cic can be dereferenced even if it's pointing to a different
queue (and thus protected under different queue_lock).

However, cic's pointing to the q which is being looked up can be
added only under the same queue_lock, so on "cic->q == q" we're
guaranteed to be looking at the right thing.

> I am wondering if there should be a small text file explaining all
> the locking in this area.

Oh, I'm gonna be restructuring ioc interface and adding ample
explanations on locking rules there.

Thanks.

--
tejun


\
 
 \ /
  Last update: 2011-10-26 22:57    [W:0.053 / U:0.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site