From: Doug Ledford <dledford@redhat.com>
To: Jens Axboe <axboe@suse.de>
Cc: Arjan Van de Ven <arjanv@redhat.com>,
Peter Yao <peter@exavio.com.cn>,
linux-kernel@vger.kernel.org,
linux-scsi mailing list <linux-scsi@vger.kernel.org>
Subject: Re: smp dead lock of io_request_lock/queue_lock patch
Date: Mon, 12 Jan 2004 08:27:53 -0500 [thread overview]
Message-ID: <1073914073.3114.263.camel@compaq.xsintricity.com> (raw)
In-Reply-To: <20040112092231.GG29177@suse.de>
On Mon, 2004-01-12 at 04:22, Jens Axboe wrote:
> On Mon, Jan 12 2004, Arjan van de Ven wrote:
> > On Mon, Jan 12, 2004 at 10:19:46AM +0100, Jens Axboe wrote:
> > >
> > > ... and still exists in your 2.4.21 based kernel.
> >
> > The RHL 2.4.21 kernels don't have the locking patch at all...
>
> But RHEL3 does:
>
> http://kernelnewbies.org/kernels/rhel3/SOURCES/linux-2.4.21-iorl.patch
>
> and the bug is there.
But in RHEL3 the bug is fixed already (not in a released kernel, but the
fix went into our internal kernel some time back and will be in our next
update kernel). From my internal bk tree for this stuff:
[dledford@compaq RHEL3-scsi]$ bk changes -r1.23
ChangeSet@1.23, 2003-11-10 17:19:54-05:00, dledford@compaq.xsintricity.com
drivers/scsi/scsi_error.c
Don't panic if the eh thread is dead, instead do the same thing that
scsi_softirq_handler does and just complete the command as a failed
command.
Change when we wake the eh thread in scsi_times_out to accomodate
the changes to the mlqueue operations.
Clear blocked status on the host and all devices in scsi_restart_operations
-> Don't grab the host_lock in scsi_restart_operations, we aren't doing
anything that needs it. Just goose the queues unconditionally,
scsi_request_fn() will know to not send commands if they shouldn't
go for some reason.
Make sure we account SCSI_STATE_MLQUEUE commands as not being failed
commands in scsi_unjam_host.
But, Jens is right, it's a real bug. I just fixed it in a different
way. And my fix is dependent on other changes in our scsi stack as
well.
--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
next prev parent reply other threads:[~2004-01-12 13:31 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-12 16:32 smp dead lock of io_request_lock/queue_lock patch Peter Yao
2004-01-12 9:08 ` Arjan van de Ven
2004-01-12 9:19 ` Jens Axboe
2004-01-12 9:19 ` Jens Axboe
2004-01-12 9:20 ` Arjan van de Ven
2004-01-12 9:22 ` Jens Axboe
2004-01-12 13:27 ` Doug Ledford [this message]
2004-01-15 17:01 ` Bill Davidsen
2004-01-15 17:05 ` Jens Axboe
2004-01-15 17:09 ` Arjan van de Ven
2004-01-15 19:30 ` Doug Ledford
-- strict thread matches above, loose matches on Subject: below --
2004-01-19 21:36 Martin Peschke3
2004-01-19 21:36 ` Martin Peschke3
2004-03-08 21:25 ` Doug Ledford
[not found] <1d6yN-6HH-17@gated-at.bofh.it>
[not found] ` <1dasC-5Ww-5@gated-at.bofh.it>
[not found] ` <1ejkf-724-13@gated-at.bofh.it>
[not found] ` <1elvB-Jt-25@gated-at.bofh.it>
2004-01-16 15:40 ` Bill Davidsen
2004-01-12 15:07 Martin Peschke3
2004-01-12 15:12 ` Arjan van de Ven
2004-01-12 19:48 ` Christoph Hellwig
2004-01-12 19:51 ` Doug Ledford
2004-01-12 20:03 ` Christoph Hellwig
2004-01-12 21:12 ` Jens Axboe
2004-01-13 20:55 ` Marcelo Tosatti
2004-01-17 13:10 ` Doug Ledford
2004-01-17 16:58 ` Christoph Hellwig
2004-01-17 19:07 ` Doug Ledford
2004-01-17 19:17 ` Christoph Hellwig
2004-01-17 19:21 ` Doug Ledford
2004-01-17 19:29 ` Christoph Hellwig
2004-01-17 20:36 ` Doug Ledford
2004-01-17 20:54 ` Christoph Hellwig
2004-01-20 7:53 ` Jens Axboe
2004-01-25 0:31 ` Kurt Garloff
2004-01-15 17:17 ` Bill Davidsen
2004-01-17 13:12 ` Doug Ledford
2004-01-17 15:16 ` Bill Davidsen
2004-01-17 16:07 ` Doug Ledford
2004-01-12 14:07 Martin Peschke3
2004-01-12 14:07 ` Martin Peschke3
2004-01-12 14:11 ` Arjan van de Ven
2004-01-12 14:13 ` Jens Axboe
2004-01-12 15:08 ` Doug Ledford
2004-01-12 15:24 ` James Bottomley
2004-01-12 15:43 ` Jens Axboe
2004-01-12 15:52 ` Doug Ledford
2004-01-12 16:04 ` James Bottomley
2004-01-12 16:05 ` Doug Ledford
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=1073914073.3114.263.camel@compaq.xsintricity.com \
--to=dledford@redhat.com \
--cc=arjanv@redhat.com \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=peter@exavio.com.cn \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.