From: Shaohua Li <shaohua.li@intel.com>
To: Tejun Heo <tj@kernel.org>
Cc: Vivek Goyal <vgoyal@redhat.com>,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
Jens Axboe <axboe@kernel.dk>
Subject: Re: Kernel crash in icq_free_icq_rcu
Date: Wed, 18 Jan 2012 14:03:22 +0800 [thread overview]
Message-ID: <1326866602.22361.624.camel@sli10-conroe> (raw)
In-Reply-To: <1326850253.22361.619.camel@sli10-conroe>
On Wed, 2012-01-18 at 09:30 +0800, Shaohua Li wrote:
> On Tue, 2012-01-17 at 17:11 -0800, Tejun Heo wrote:
> > On Wed, Jan 18, 2012 at 09:05:26AM +0800, Shaohua Li wrote:
> > > > Vivek is seeing the problem while switching elevators. Are you too?
> > > > Or is it during normal operation?
> > > same here. I had some problems when I debug my ioscheduler, but
> > > eventually found even switching cfq and noop can trigger oops.
> >
> > Hmmm... maybe quiescing isn't working as expected and kmem cache is
> > being destroyed with live icq's. I'll try to reproduce it.
> this debug patch seems to fix for me.
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index e6c05a9..c6a8ef5 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -872,11 +872,11 @@ retry:
> spin_unlock_irq(q->queue_lock);
>
> /* create icq if missing */
> - if (unlikely(et->icq_cache && !icq))
> + if (unlikely(et->icq_cache && !icq && (rw_flags & REQ_ELVPRIV)))
> icq = ioc_create_icq(q, gfp_mask);
>
> /* rqs are guaranteed to have icq on elv_set_request() if requested */
> - if (likely(!et->icq_cache || icq))
> + if (likely(!et->icq_cache || icq || !(rw_flags & REQ_ELVPRIV)))
> rq = blk_alloc_request(q, icq, rw_flags, gfp_mask);
>
> if (unlikely(!rq)) {
>
Here is the formal patch. I hope it fixes all the problems related to
icq_cache, but please open an eye :)
Subject: block: fix NULL icq_cache reference
CPU0: CPU1:
switch from cfq to noop
elv_quiesce_start
C: get_request
A: ioc_create_icq
alloc icq with cfq
B: do elevator switch
ioc_clear_queue
elv_quiesce_end
insert icq to ioc
switch from noop to cfq
elv_quiesce_start
do elevator switch
ioc_clear_queue
elv_quiesce_end
CPU0 leaves some icq to ioc list after elevator is switching from cfq to noop.
in the second ioc_clear_queue, the ioc has icq in its list, but current
elevator is noop. so ioc_exit_icq will get a NULL et->icq_cache.
In above cases, if A runs after B, ioc_create_icq will have a NULL
et->icq_cache, this will trigger another crash.
Note, get_request caches et without lock hold. Between C and A, a elevator
switch can start. But we will have elvpriv++, elv_quiesce_start will drain
all requests first. So this will not trigger crash.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
---
block/blk-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux/block/blk-core.c
===================================================================
--- linux.orig/block/blk-core.c 2012-01-18 12:44:13.000000000 +0800
+++ linux/block/blk-core.c 2012-01-18 12:45:28.000000000 +0800
@@ -872,11 +872,11 @@ retry:
spin_unlock_irq(q->queue_lock);
/* create icq if missing */
- if (unlikely(et->icq_cache && !icq))
+ if (unlikely(et->icq_cache && !icq && (rw_flags & REQ_ELVPRIV)))
icq = ioc_create_icq(q, gfp_mask);
/* rqs are guaranteed to have icq on elv_set_request() if requested */
- if (likely(!et->icq_cache || icq))
+ if (likely(!et->icq_cache || icq || !(rw_flags & REQ_ELVPRIV)))
rq = blk_alloc_request(q, icq, rw_flags, gfp_mask);
if (unlikely(!rq)) {
next prev parent reply other threads:[~2012-01-18 6:02 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-17 20:18 Vivek Goyal
2012-01-17 20:19 ` Jens Axboe
2012-01-17 20:40 ` Vivek Goyal
2012-01-17 20:42 ` Jens Axboe
2012-01-17 20:58 ` Vivek Goyal
2012-01-17 21:01 ` Vivek Goyal
2012-01-17 21:48 ` Tejun Heo
2012-01-17 22:07 ` Vivek Goyal
2012-01-18 1:01 ` Shaohua Li
2012-01-18 1:03 ` Tejun Heo
2012-01-18 1:05 ` Shaohua Li
2012-01-18 1:11 ` Tejun Heo
2012-01-18 1:30 ` Shaohua Li
2012-01-18 2:26 ` Shaohua Li
2012-01-18 4:23 ` Shaohua Li
2012-01-18 6:03 ` Shaohua Li [this message]
2012-01-18 13:51 ` Vivek Goyal
2012-01-18 14:20 ` Vivek Goyal
2012-01-18 16:09 ` Tejun Heo
2012-01-18 16:24 ` Jens Axboe
2012-01-18 16:31 ` Jens Axboe
2012-01-18 16:36 ` Vivek Goyal
2012-01-18 17:10 ` Tejun Heo
2012-01-18 19:07 ` Jens Axboe
2012-01-18 19:05 ` Jens Axboe
2012-01-18 16:55 ` Tejun Heo
2012-01-18 16:07 ` Tejun Heo
2012-01-19 1:41 ` [patch]block: fix NULL icq_cache reference Shaohua Li
2012-01-19 1:43 ` Tejun Heo
2012-01-19 8:20 ` Jens Axboe
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=1326866602.22361.624.camel@sli10-conroe \
--to=shaohua.li@intel.com \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=vgoyal@redhat.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
all inboxes | Powered by JetHome®