From: "Justin T. Gibbs" <Justin_Gibbs@adaptec.com>
To: linux-scsi@vger.kernel.org
Subject: [PATCH] 2.4.X Avoid excessive recursion when setting device offline
Date: Mon, 29 Mar 2004 10:07:00 -0700 [thread overview]
Message-ID: <387680000.1080580020@aslan.btc.adaptec.com> (raw)
How to reproduce: Queue up lots of I/O to a device. Set that device
offline.
Result: The SCSI mid-layer blows out the kernel stack due to the inherent
recursion in its request function. The repeating stack trace goes
something like:
scsi_request_fn
__scsi_end_request
scsi_release_command
scsi_queue_next_request
scsi_request_fn
...
This patch prevents recursive calls through the scsi_request_fn
for the same queue:
===== scsi.h 1.9 vs edited =====
--- 1.9/drivers/scsi/scsi.h Wed Jun 25 17:34:08 2003
+++ edited/scsi.h Sun Mar 28 13:50:35 2004
@@ -609,6 +609,7 @@
unsigned starved:1; /* unable to process commands because
host busy */
unsigned no_start_on_add:1; /* do not issue start on add */
+ unsigned running_request_fn:1;
// Flag to allow revalidate to succeed in sd_open
int allow_revalidate;
===== scsi_lib.c 1.17 vs edited =====
--- 1.17/drivers/scsi/scsi_lib.c Fri Jul 4 11:12:45 2003
+++ edited/scsi_lib.c Sun Mar 28 14:07:48 2004
@@ -850,12 +850,20 @@
if (!SDpnt) {
panic("Missing device");
}
+
SHpnt = SDpnt->host;
/*
* To start with, we keep looping until the queue is empty, or until
- * the host is no longer able to accept any more requests.
+ * the host is no longer able to accept any more requests. We avoid
+ * excessive recursion through the SCSI layer by recording that we
+ * are running this queue and rejecting requests to run it again. This
+ * avoids blowing out the stack when multiple commands are failed
+ * during our loop.
*/
+ if (SDpnt->running_request_fn)
+ return;
+ SDpnt->running_request_fn = 1;
while (1 == 1) {
/*
* Check this again - each time we loop through we will have
@@ -863,7 +871,7 @@
* we need to check to see if the queue is plugged or not.
*/
if (SHpnt->in_recovery || q->plugged)
- return;
+ break;
/*
* If the device cannot accept another request, then quit.
@@ -1099,6 +1107,7 @@
*/
spin_lock_irq(&io_request_lock);
}
+ SDpnt->running_request_fn = 0;
}
/*
next reply other threads:[~2004-03-29 17:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-29 17:07 Justin T. Gibbs [this message]
2004-03-29 17:26 ` [PATCH] 2.4.X Avoid excessive recursion when setting device offline Arjan van de Ven
2004-03-29 17:42 ` Justin T. Gibbs
2004-03-29 17:47 ` James Bottomley
2004-03-29 17:52 ` Justin T. Gibbs
2004-03-30 7:03 ` 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=387680000.1080580020@aslan.btc.adaptec.com \
--to=justin_gibbs@adaptec.com \
--cc=linux-scsi@vger.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