From: Vivek Goyal <vgoyal@redhat.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
Jens Axboe <jens.axboe@oracle.com>,
Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Subject: Re: [PATCH] blk-cgroup: Fix RCU correctness warning in cfq_init_queue()
Date: Mon, 26 Apr 2010 09:39:20 -0400 [thread overview]
Message-ID: <20100426133920.GA1559@redhat.com> (raw)
In-Reply-To: <20100426020631.GU2440@linux.vnet.ibm.com>
On Sun, Apr 25, 2010 at 07:06:31PM -0700, Paul E. McKenney wrote:
> On Mon, Apr 26, 2010 at 09:33:46AM +0800, Li Zefan wrote:
> > >>>>>> With RCU correctness on, We see following warning. This patch fixes it.
> > >>>>> This is in initialization code, so that there cannot be any concurrent
> > >>>>> updates, correct? If so, looks good.
> > >>>>>
> > >>>> I think theoritically two instances of cfq_init_queue() can be running
> > >>>> in parallel (for two different devices), and they both can call
> > >>>> blkiocg_add_blkio_group(). But then we use a spin lock to protect
> > >>>> blkio_cgroup.
> > >>>>
> > >>>> spin_lock_irqsave(&blkcg->lock, flags);
> > >>>>
> > >>>> So I guess two parallel updates should be fine.
> > >>> OK, in that case, would it be possible add this spinlock to the condition
> > >>> checked by css_id()'s rcu_dereference_check()?
> > >> Hi Paul,
> > >>
> > >> I think adding these spinlock to condition checked might become little
> > >> messy. And the reason being that this lock is subsystem (controller)
> > >> specific and maintained by controller. Now if any controller implements
> > >> a lock and we add that lock in css_id() rcu_dereference_check(), it will
> > >> look ugly.
> > >>
> > >> So probably a better way is to make sure that css_id() is always called
> > >> under rcu read lock so that we don't hit this warning?
> > >
> > > As long as holding rcu_read_lock() prevents css_id() from the usual
> > > problems such as access memory that was concurrently freed, yes.
> >
> > blkiocg_add_blkio_group() also calls cgroup_path(), which also needs to
> > be called within rcu_read_lock, so I think Vivek's patch is better than
> > the one you posted in another mail thread.
>
> My apologies, Vivek! I lost track of your patch. I have now replaced
> my patch with yours.
Thanks Paul.
I sent this patch to Jens also, thinking he will apply to his tree. Looks
like he has not applied it yet though.
Jens, is it ok if this patch gets merged through paul's tree or should it
go through blk tree?
Thanks
Vivek
next prev parent reply other threads:[~2010-04-26 13:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-22 15:54 [PATCH] blk-cgroup: Fix RCU correctness warning in cfq_init_queue() Vivek Goyal
2010-04-22 23:15 ` Paul E. McKenney
2010-04-22 23:55 ` Vivek Goyal
2010-04-23 0:17 ` Paul E. McKenney
2010-04-23 14:41 ` Vivek Goyal
2010-04-23 19:46 ` Paul E. McKenney
2010-04-26 1:33 ` Li Zefan
2010-04-26 2:06 ` Paul E. McKenney
2010-04-26 13:39 ` Vivek Goyal [this message]
2010-04-26 14:45 ` Paul E. McKenney
2010-04-26 20:42 ` Vivek Goyal
2010-04-26 20:47 ` Paul E. McKenney
2010-04-26 20:52 ` Vivek Goyal
2010-04-28 0:16 ` Paul E. McKenney
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=20100426133920.GA1559@redhat.com \
--to=vgoyal@redhat.com \
--cc=guijianfeng@cn.fujitsu.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=paulmck@linux.vnet.ibm.com \
/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).