[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1314179992.24121.3.camel@twins>
Date: Wed, 24 Aug 2011 11:59:52 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: linux-scsi <linux-scsi@...r.kernel.org>,
Frank Rowand <frank.rowand@...sony.com>,
Oleg Nesterov <oleg@...hat.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
hch <hch@...radead.org>, "yong.zhang0" <yong.zhang0@...il.com>,
scameron@...rdog.cce.hp.com, Jens Axboe <jaxboe@...ionio.com>,
Thomas Gleixner <tglx@...utronix.de>, users@...nel.org
Subject: Re: [kernel.org users] [KORG] Panics on master backend
On Tue, 2011-08-23 at 16:32 -0500, James Bottomley wrote:
> > scsi_request_fn(), which does:
> >
> > /*
> > * XXX(hch): This is rather suboptimal, scsi_dispatch_cmd will
> > * take the lock again.
> > */
> > spin_unlock_irq(shost->host_lock);
>
> Um, that one looks like a mistake missed in cleanup (probably years
> ago). The other host_lock acquisitions aren't _irq, so this one
> shouldn't be either. I can patch it up (or you can).
I would much appreciate if someone who knows that whole stack would
audit it, my preferred solution is removing that blk plug stuff from the
scheduler guts since clearly nobody bothered making sure its sane.
Something like the three patches below, lifted from -rt:
sched-separate-the-scheduler-entry-for-preemption.patch
sched-move-blk_schedule_flush_plug-out-of-__schedule.patch
block-shorten-interrupt-disabled-regions.patch
View attachment "block-shorten-interrupt-disabled-regions.patch" of type "text/x-patch" (3653 bytes)
View attachment "sched-move-blk_schedule_flush_plug-out-of-__schedule.patch" of type "text/x-patch" (2095 bytes)
View attachment "sched-separate-the-scheduler-entry-for-preemption.patch" of type "text/x-patch" (2433 bytes)
Powered by blists - more mailing lists