From: Vivek Goyal <vgoyal@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: axboe@kernel.dk, ctalbott@google.com, rni@google.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/9] blkcg: drop unnecessary RCU locking
Date: Fri, 17 Feb 2012 12:28:57 -0500 [thread overview]
Message-ID: <20120217172857.GD26620@redhat.com> (raw)
In-Reply-To: <20120217171113.GB26575@google.com>
On Fri, Feb 17, 2012 at 09:11:13AM -0800, Tejun Heo wrote:
> On Fri, Feb 17, 2012 at 11:47:49AM -0500, Vivek Goyal wrote:
> > 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.
>
> So, this should be okay. It's currently not because blkg_alloc() is
> broken due to percpu allocation but other than that calling both w/
> and w/o RCU read lock should be fine.
>
> > 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?
>
> No, why would it be a problem?
I am kind of confused that what are the semantics of calling
blkg_lookup_create(). Given the fact that it traverses the
blkcg->blkg_list which is rcu protected, so either we should have
rcu read lock held or we should have blkcg->lock held.
So there might not be any problem, just that looking at the code
I am not very clear abou the locking sematics of blkg_lookup(). May
be some documentation will help that it should be called with
what locks in what situation. Specifically, when should it be called
with rcu_read_lock() held.
>
> > We might be examining a blkg belonging to a different queue and it
> > might be being freed parallely.
>
> How?
Can pre_destroy() and blkio_policy_parse_and_set() make progress in
parallel for same cgroup(blkcg) but different queue.
If yes, blkg_lookup() might be doing blkg->q == q check and pre_destroy
might delete that group and free it up.
Thanks
Vivek
next prev parent reply other threads:[~2012-02-17 17:29 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-16 22:37 [PATCHSET] blkcg: update locking and fix stacking Tejun Heo
2012-02-16 22:37 ` [PATCH 1/9] blkcg: use double locking instead of RCU for blkg synchronization Tejun Heo
2012-02-16 22:37 ` [PATCH 2/9] blkcg: drop unnecessary RCU locking Tejun Heo
2012-02-17 16:19 ` Vivek Goyal
2012-02-17 17:07 ` Tejun Heo
2012-02-17 17:14 ` Tejun Heo
2012-02-17 16:47 ` Vivek Goyal
2012-02-17 17:11 ` Tejun Heo
2012-02-17 17:28 ` Vivek Goyal [this message]
2012-02-17 17:43 ` Tejun Heo
2012-02-17 18:08 ` Vivek Goyal
2012-02-17 18:16 ` Tejun Heo
2012-02-22 0:49 ` [PATCH UPDATED " Tejun Heo
2012-02-16 22:37 ` [PATCH 3/9] block: restructure get_request() Tejun Heo
2012-02-16 22:37 ` [PATCH 4/9] block: interface update for ioc/icq creation functions Tejun Heo
2012-02-16 22:37 ` [PATCH 5/9] block: ioc_task_link() can't fail Tejun Heo
2012-02-17 20:41 ` Vivek Goyal
2012-02-17 22:18 ` Tejun Heo
2012-02-16 22:37 ` [PATCH 6/9] block: add io_context->active_ref Tejun Heo
2012-02-16 22:37 ` [PATCH 7/9] block: implement bio_associate_current() Tejun Heo
2012-02-17 1:19 ` Kent Overstreet
2012-02-17 22:14 ` Tejun Heo
2012-02-17 22:34 ` Vivek Goyal
2012-02-17 22:41 ` Tejun Heo
2012-02-17 22:51 ` Vivek Goyal
2012-02-17 22:57 ` Tejun Heo
2012-02-20 14:22 ` Vivek Goyal
2012-02-20 16:59 ` Tejun Heo
2012-02-20 19:14 ` Vivek Goyal
2012-02-20 21:21 ` Tejun Heo
2012-02-27 23:12 ` Chris Wright
2012-02-28 14:10 ` Vivek Goyal
2012-02-28 17:01 ` Chris Wright
2012-02-28 20:11 ` Stefan Hajnoczi
2012-02-20 14:36 ` Vivek Goyal
2012-02-20 17:01 ` Tejun Heo
2012-02-20 19:16 ` Vivek Goyal
2012-02-20 21:06 ` Tejun Heo
2012-02-20 21:10 ` Vivek Goyal
2012-02-17 22:56 ` Vivek Goyal
2012-02-17 23:06 ` Tejun Heo
2012-02-17 21:33 ` Vivek Goyal
2012-02-17 22:03 ` Tejun Heo
2012-02-17 22:29 ` Vivek Goyal
2012-02-17 22:38 ` Tejun Heo
2012-02-17 22:42 ` Tejun Heo
2012-02-16 22:37 ` [PATCH 8/9] block: make block cgroup policies follow bio task association Tejun Heo
2012-02-16 22:37 ` [PATCH 9/9] block: make blk-throttle preserve the issuing task on delayed bios Tejun Heo
2012-02-17 21:58 ` Vivek Goyal
2012-02-17 22:17 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120217172857.GD26620@redhat.com \
--to=vgoyal@redhat.com \
--cc=axboe@kernel.dk \
--cc=ctalbott@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rni@google.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).