Re: [PATCH 5/8] blkcg: make sure blkg_lookup() returns %NULL if @qis bypassing

From: Vivek Goyal
Date: Fri Apr 13 2012 - 13:24:13 EST


On Fri, Apr 13, 2012 at 10:03:34AM -0700, Tejun Heo wrote:
> Hey,
>
> On Fri, Apr 13, 2012 at 12:00:53PM -0400, Vivek Goyal wrote:
> > On Thu, Apr 12, 2012 at 04:29:37PM -0700, Tejun Heo wrote:
> >
> > [..]
> > > * In bypass mode, only the dispatch FIFO queue of @q is used. This
> > > * function makes @q enter bypass mode and drains all requests which were
> > > * throttled or issued before. On return, it's guaranteed that no request
> > > - * is being throttled or has ELVPRIV set.
> > > + * is being throttled or has ELVPRIV set and blk_queue_bypass() is %true
> > > + * inside queue or RCU read lock.
> > > */
> > > void blk_queue_bypass_start(struct request_queue *q)
> > > {
> > > @@ -426,6 +427,7 @@ void blk_queue_bypass_start(struct request_queue *q)
> > > spin_unlock_irq(q->queue_lock);
> > >
> > > blk_drain_queue(q, false);
> > > + synchronize_rcu();
> >
> > I guess this synchronize_rcu() needs some comments here to make it clear
> > what it meant for. IIUC, you are protecting against policy data (stats
> > update) which happen under rcu in throttling code? You want to make sure
> > all these updaters are done before you go ahead with
> > activation/deactivation of a policy.
> >
> > Well, I am wondering if CFQ is policy being activated/deactivated why
> > should we try to drain other policie's requests. Can't one continue
> > to work without draining all the throttled requests. We probably just
> > need to make sure new groups are not created.
>
> So, I think synchronization rules like this are something which the
> core should define. cfq may not use it but the sync rules should
> still be the same for all policies. In this case, what the core
> provides is "blk_queue_bypass() is guaranteed to be seen as %true
> inside RCU read lock section once this function returns", which in
> turn will guarantee that RCU read-lock protected blkg_lookup() is
> guaranteed to fail once the function returns. This property makes RCU
> protected blkg_lookup() safe against queue bypassing, which is what we
> want.

I think now synchronize_rcu() has become part of cfq_init_queue()
effectively and that will slow down boot. In the past I had to remove
it.

Thanks
Vivek
--
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/