[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111026205455.GG24261@google.com>
Date: Wed, 26 Oct 2011 13:54:55 -0700
From: Tejun Heo <tj@...nel.org>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: axboe@...nel.dk, ctalbott@...gle.com, rni@...gle.com,
linux-kernel@...r.kernel.org
Subject: Re: [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
--
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