Re: [PATCH 10/13] block, cfq: unlink cfq_io_context's immediately

[Tejun Heo]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/