* [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
@ 2008-03-11 22:10 Michael Reed
2008-03-12 10:46 ` Boaz Harrosh
2008-03-17 18:08 ` Mike Christie
0 siblings, 2 replies; 18+ messages in thread
From: Michael Reed @ 2008-03-11 22:10 UTC (permalink / raw)
To: Douglas Gilbert; +Cc: linux-scsi, Jeremy Higdon, James Bottomley
Note: description below applies to 2.6.24 as that's what was used to
isolate the problem being described. There are comments at the end
with regard to 2.6.25-rc4-git3. The below email thread directly
applies to this bug/patch.
http://marc.info/?l=linux-scsi&m=120222578814366&w=2
--
While performing raid reset testing using 2.6.24, every once in the
while I noticed that one of the raid's management tools would not exit.
I tracked this down to it waiting on an inquiry command's completion.
An infinite loop occurs because there is an occasional inquiry
command submitted to the host driver with the associated bio
having a bi_size field of 512 when the inquiry command's transfer
length is 255. This "enlarged" bi_size field causes the completion
handler to re-issue the inquiry command because there are "leftovers"
following the completion.
scsi_finish_command() calls scsi_io_completion() with
good_bytes equal to cmd->request_bufflen.
scsi_io_completion() sets req->data_len to the residual provided
by the LLDD.
scsi_io_completion() calls scsi_end_request() with the good_bytes
value of 255.
scsi_end_request() calls end_that_request_chunk() which calls
__end_that_request_first() which uses bio->bi_size as the size of
the request. As bi_size is larger than the number of bytes (nr_bytes)
being completed, it returns "1" indicating that there wasn't enough
data to finish the request.
scsi_end_request() then calls scsi_requeue_command() to resubmit and
fetch that data which wasn't received. This results in the
command being reissued using the residual value returned by
the driver as the request_bufflen for the next command.
This repeats itself until the residual is zero and bi_size is
non-zero at which point the command gets reissued with a
request_bufflen of zero and sc_data_direction of DMA_NONE.
The subsequent completions are retried infinitely because
bi_size is still non-zero.
What drove me crazy is that this didn't happen with every inquiry
command issued by the application. It was very infrequent.
I finally tracked it down to the sg driver.
sg_ioctl() calls sg_new_write() which calls sg_common_write()
which calls sg_start_req().
sg_start_req() either calls sg_link_reserve() or sg_build_indirect()
to set up the data transfer. The call to sg_build_indirect()
ROUNDS UP THE REQUEST SIZE to a sector boundary, and this is what
causes the infinite loop.
I tried removing the round up statement in sg_build_indirect()
and forcing sg_start_req() to always call sg_build_indirect()
to test the change and the infinite loop did not occur.
To me, it seems that if sg_link_reserve() has no need to round up
to a sector boundary then sg_build_indirect() should also not need
to round up the request length.
I've included a patch (against 2.6.25-rc4-git3) which removes the
rounding in sg_build_indirect() for your comments.
I then tried my test case with 2.6.25-rc4-git3 and it didn't happen.
I noticed the change in the routine scsi_req_map_sg() which
deletes a line which incremented the "data_len" variable at the start
of the for_each_sg() loop. This was also a line which I examined in 6.5.24.
But, I noticed comments about sg indicating that it "sends a scatterlist
that is larger than the data_len it wants transferred for certain
IO sizes", and as that appeared to be what was happening, I went in
search of what was up with sg.
So, will the below patch break anything?
Signed-off-by: Michael Reed <mdr@sgi.com>
--- linux-2.6.25-rc4-git3/drivers/scsi/sg.c 2008-03-10 13:21:06.000000000 -0700
+++ linux-2.6.25-rc4-git3-modified/drivers/scsi/sg.c 2008-03-11 14:47:32.376281307 -0700
@@ -1829,17 +1829,13 @@
struct scatterlist *sg;
int ret_sz = 0, k, rem_sz, num, mx_sc_elems;
int sg_tablesize = sfp->parentdp->sg_tablesize;
- int blk_size = buff_size;
struct page *p = NULL;
- if (blk_size < 0)
+ if (buff_size < 0)
return -EFAULT;
- if (0 == blk_size)
- ++blk_size; /* don't know why */
-/* round request up to next highest SG_SECTOR_SZ byte boundary */
- blk_size = (blk_size + SG_SECTOR_MSK) & (~SG_SECTOR_MSK);
- SCSI_LOG_TIMEOUT(4, printk("sg_build_indirect: buff_size=%d, blk_size=%d\n",
- buff_size, blk_size));
+
+ SCSI_LOG_TIMEOUT(4, printk("sg_build_indirect: buff_size=%d\n",
+ buff_size));
/* N.B. ret_sz carried into this block ... */
mx_sc_elems = sg_build_sgat(schp, sfp, sg_tablesize);
@@ -1854,7 +1850,7 @@
} else
scatter_elem_sz_prev = num;
}
- for (k = 0, sg = schp->buffer, rem_sz = blk_size;
+ for (k = 0, sg = schp->buffer, rem_sz = buff_size;
(rem_sz > 0) && (k < mx_sc_elems);
++k, rem_sz -= ret_sz, sg = sg_next(sg)) {
@@ -1880,7 +1876,7 @@
SCSI_LOG_TIMEOUT(5, printk("sg_build_indirect: k_use_sg=%d, "
"rem_sz=%d\n", k, rem_sz));
- schp->bufflen = blk_size;
+ schp->bufflen = buff_size;
if (rem_sz > 0) /* must have failed */
return -ENOMEM;
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-11 22:10 [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24 Michael Reed
@ 2008-03-12 10:46 ` Boaz Harrosh
2008-03-12 16:03 ` Michael Reed
2008-03-17 18:08 ` Mike Christie
1 sibling, 1 reply; 18+ messages in thread
From: Boaz Harrosh @ 2008-03-12 10:46 UTC (permalink / raw)
To: Michael Reed, James Bottomley, Mike Christie
Cc: Douglas Gilbert, linux-scsi, Jeremy Higdon
On Wed, Mar 12 2008 at 0:10 +0200, Michael Reed <mdr@sgi.com> wrote:
> Note: description below applies to 2.6.24 as that's what was used to
> isolate the problem being described. There are comments at the end
> with regard to 2.6.25-rc4-git3. The below email thread directly
> applies to this bug/patch.
>
> http://marc.info/?l=linux-scsi&m=120222578814366&w=2
>
> --
>
> While performing raid reset testing using 2.6.24, every once in the
> while I noticed that one of the raid's management tools would not exit.
> I tracked this down to it waiting on an inquiry command's completion.
>
> An infinite loop occurs because there is an occasional inquiry
> command submitted to the host driver with the associated bio
> having a bi_size field of 512 when the inquiry command's transfer
> length is 255. This "enlarged" bi_size field causes the completion
> handler to re-issue the inquiry command because there are "leftovers"
> following the completion.
>
> scsi_finish_command() calls scsi_io_completion() with
> good_bytes equal to cmd->request_bufflen.
>
> scsi_io_completion() sets req->data_len to the residual provided
> by the LLDD.
>
> scsi_io_completion() calls scsi_end_request() with the good_bytes
> value of 255.
>
> scsi_end_request() calls end_that_request_chunk() which calls
> __end_that_request_first() which uses bio->bi_size as the size of
> the request. As bi_size is larger than the number of bytes (nr_bytes)
> being completed, it returns "1" indicating that there wasn't enough
> data to finish the request.
>
> scsi_end_request() then calls scsi_requeue_command() to resubmit and
> fetch that data which wasn't received. This results in the
> command being reissued using the residual value returned by
> the driver as the request_bufflen for the next command.
>
> This repeats itself until the residual is zero and bi_size is
> non-zero at which point the command gets reissued with a
> request_bufflen of zero and sc_data_direction of DMA_NONE.
> The subsequent completions are retried infinitely because
> bi_size is still non-zero.
>
> What drove me crazy is that this didn't happen with every inquiry
> command issued by the application. It was very infrequent.
> I finally tracked it down to the sg driver.
>
> sg_ioctl() calls sg_new_write() which calls sg_common_write()
> which calls sg_start_req().
>
> sg_start_req() either calls sg_link_reserve() or sg_build_indirect()
> to set up the data transfer. The call to sg_build_indirect()
> ROUNDS UP THE REQUEST SIZE to a sector boundary, and this is what
> causes the infinite loop.
>
> I tried removing the round up statement in sg_build_indirect()
> and forcing sg_start_req() to always call sg_build_indirect()
> to test the change and the infinite loop did not occur.
>
> To me, it seems that if sg_link_reserve() has no need to round up
> to a sector boundary then sg_build_indirect() should also not need
> to round up the request length.
>
> I've included a patch (against 2.6.25-rc4-git3) which removes the
> rounding in sg_build_indirect() for your comments.
>
> I then tried my test case with 2.6.25-rc4-git3 and it didn't happen.
> I noticed the change in the routine scsi_req_map_sg() which
> deletes a line which incremented the "data_len" variable at the start
> of the for_each_sg() loop. This was also a line which I examined in 6.5.24.
> But, I noticed comments about sg indicating that it "sends a scatterlist
> that is larger than the data_len it wants transferred for certain
> IO sizes", and as that appeared to be what was happening, I went in
> search of what was up with sg.
>
> So, will the below patch break anything?
>
> Signed-off-by: Michael Reed <mdr@sgi.com>
>
>
<snip>
All these patches do not solve the root cause of the problem and until
solved, (easily) they will keep popping up.
The root cause is that BLOCK_PC commands *can not* be retried in chunks.
The midlayer has no way to know how to retry them. and any attempt to do so
will result in an illegal scsi command.
I'm really sorry for not seeing this before. I have seen all these emails
and patches back and forth but they addressed such remote locations, that
I have not paid attention to them.
So lets try to touch base. BLOCK_PC command can only be completed in full
always. In case of error or residual this should be properly reported and
that is all the midlayer can do. The Initiator That knows what command was
sent will then decide on a retry or not. In above case that will be user
mode.
Just to demonstrate what I mean a patch is attached. Just as an RFC, totally
untested.
---
git-diff --stat -p
drivers/scsi/scsi_lib.c | 29 ++++++++++++++++-------------
1 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index ba21d97..e5d05c6 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -784,17 +784,24 @@ EXPORT_SYMBOL(scsi_release_buffers);
* in req->data_len and req->next_rq->data_len. The upper-layer driver can
* decide what to do with this information.
*/
-void scsi_end_bidi_request(struct scsi_cmnd *cmd)
+static void scsi_end_blk_request(struct scsi_cmnd *cmd)
{
struct request *req = cmd->request;
unsigned int dlen = req->data_len;
- unsigned int next_dlen = req->next_rq->data_len;
+ unsigned int next_dlen;
- req->data_len = scsi_out(cmd)->resid;
- req->next_rq->data_len = scsi_in(cmd)->resid;
+ if (blk_bidi_rq(req)) {
+ next_dlen = req->next_rq->data_len;
+ req->data_len = scsi_out(cmd)->resid;
+ req->next_rq->data_len = scsi_in(cmd)->resid;
+ } else {
+ next_dlen = 0;
+ req->data_len = scsi_get_resid(cmd);
+ }
- /* The req and req->next_rq have not been completed */
- BUG_ON(blk_end_bidi_request(req, 0, dlen, next_dlen));
+ if (blk_end_bidi_request(req, 0, dlen, next_dlen))
+ /* The req and req->next_rq have not been completed */
+ BUG_ON();
scsi_release_buffers(cmd);
@@ -866,15 +873,11 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
req->sense_len = len;
}
}
- if (scsi_bidi_cmnd(cmd)) {
- /* will also release_buffers */
- scsi_end_bidi_request(cmd);
- return;
- }
- req->data_len = scsi_get_resid(cmd);
+ /* will also release_buffers */
+ scsi_end_blk_request(cmd);
+ return;
}
- BUG_ON(blk_bidi_rq(req)); /* bidi not support for !blk_pc_request yet */
scsi_release_buffers(cmd);
/*
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-12 10:46 ` Boaz Harrosh
@ 2008-03-12 16:03 ` Michael Reed
2008-03-12 16:09 ` Boaz Harrosh
0 siblings, 1 reply; 18+ messages in thread
From: Michael Reed @ 2008-03-12 16:03 UTC (permalink / raw)
To: Boaz Harrosh
Cc: James Bottomley, Mike Christie, Douglas Gilbert, linux-scsi,
Jeremy Higdon
Boaz Harrosh wrote:
<snip>
>
> All these patches do not solve the root cause of the problem and until
> solved, (easily) they will keep popping up.
I will ask that the correctness of the sg driver's construction of
a scatter list also be considered here. Is it ever correct for bi_size
to wind up larger than the request size? Why is rounding needed in one
case (sg_build_indirect) but not the other (sg_link_reserve)?
> The root cause is that BLOCK_PC commands *can not* be retried in chunks.
> The midlayer has no way to know how to retry them. and any attempt to do so
> will result in an illegal scsi command.
>
> I'm really sorry for not seeing this before. I have seen all these emails
> and patches back and forth but they addressed such remote locations, that
> I have not paid attention to them.
>
> So lets try to touch base. BLOCK_PC command can only be completed in full
> always. In case of error or residual this should be properly reported and
> that is all the midlayer can do. The Initiator That knows what command was
> sent will then decide on a retry or not. In above case that will be user
> mode.
Those who truly understand this should comment. It makes sense to this
novice.
>
> Just to demonstrate what I mean a patch is attached. Just as an RFC, totally
> untested.
I can try this out and see what happens.
Mike
> ---
> git-diff --stat -p
> drivers/scsi/scsi_lib.c | 29 ++++++++++++++++-------------
> 1 files changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index ba21d97..e5d05c6 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -784,17 +784,24 @@ EXPORT_SYMBOL(scsi_release_buffers);
> * in req->data_len and req->next_rq->data_len. The upper-layer driver can
> * decide what to do with this information.
> */
> -void scsi_end_bidi_request(struct scsi_cmnd *cmd)
> +static void scsi_end_blk_request(struct scsi_cmnd *cmd)
> {
> struct request *req = cmd->request;
> unsigned int dlen = req->data_len;
> - unsigned int next_dlen = req->next_rq->data_len;
> + unsigned int next_dlen;
>
> - req->data_len = scsi_out(cmd)->resid;
> - req->next_rq->data_len = scsi_in(cmd)->resid;
> + if (blk_bidi_rq(req)) {
> + next_dlen = req->next_rq->data_len;
> + req->data_len = scsi_out(cmd)->resid;
> + req->next_rq->data_len = scsi_in(cmd)->resid;
> + } else {
> + next_dlen = 0;
> + req->data_len = scsi_get_resid(cmd);
> + }
>
> - /* The req and req->next_rq have not been completed */
> - BUG_ON(blk_end_bidi_request(req, 0, dlen, next_dlen));
> + if (blk_end_bidi_request(req, 0, dlen, next_dlen))
> + /* The req and req->next_rq have not been completed */
> + BUG_ON();
>
> scsi_release_buffers(cmd);
>
> @@ -866,15 +873,11 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
> req->sense_len = len;
> }
> }
> - if (scsi_bidi_cmnd(cmd)) {
> - /* will also release_buffers */
> - scsi_end_bidi_request(cmd);
> - return;
> - }
> - req->data_len = scsi_get_resid(cmd);
> + /* will also release_buffers */
> + scsi_end_blk_request(cmd);
> + return;
> }
>
> - BUG_ON(blk_bidi_rq(req)); /* bidi not support for !blk_pc_request yet */
> scsi_release_buffers(cmd);
>
> /*
>
>
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-12 16:03 ` Michael Reed
@ 2008-03-12 16:09 ` Boaz Harrosh
2008-03-14 13:11 ` Michael Reed
0 siblings, 1 reply; 18+ messages in thread
From: Boaz Harrosh @ 2008-03-12 16:09 UTC (permalink / raw)
To: Michael Reed
Cc: James Bottomley, Mike Christie, Douglas Gilbert, linux-scsi,
Jeremy Higdon
On Wed, Mar 12 2008 at 18:03 +0200, Michael Reed <mdr@sgi.com> wrote:
>
> Boaz Harrosh wrote:
>
> <snip>
>
>> All these patches do not solve the root cause of the problem and until
>> solved, (easily) they will keep popping up.
>
> I will ask that the correctness of the sg driver's construction of
> a scatter list also be considered here. Is it ever correct for bi_size
> to wind up larger than the request size? Why is rounding needed in one
> case (sg_build_indirect) but not the other (sg_link_reserve)?
>
>> The root cause is that BLOCK_PC commands *can not* be retried in chunks.
>> The midlayer has no way to know how to retry them. and any attempt to do so
>> will result in an illegal scsi command.
>>
>> I'm really sorry for not seeing this before. I have seen all these emails
>> and patches back and forth but they addressed such remote locations, that
>> I have not paid attention to them.
>>
>> So lets try to touch base. BLOCK_PC command can only be completed in full
>> always. In case of error or residual this should be properly reported and
>> that is all the midlayer can do. The Initiator That knows what command was
>> sent will then decide on a retry or not. In above case that will be user
>> mode.
>
> Those who truly understand this should comment. It makes sense to this
> novice.
>
>> Just to demonstrate what I mean a patch is attached. Just as an RFC, totally
>> untested.
>
> I can try this out and see what happens.
>
>
Will not compile here is a cleaner one
---
From: Boaz Harrosh <bharrosh@panasas.com>
Date: Wed, 12 Mar 2008 13:18:49 +0200
Subject: [PATCH] scsi: Always complete BLOCK_PC commands
Current code, in some IO combinations could wrongly retry
a BLOCK_PC command in chunks. This was never intended.
Fix it that BLOCK_PC will always complete atomically
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
---
drivers/scsi/scsi_lib.c | 24 +++++++++++++-----------
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index ba21d97..4b8b57c 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -784,14 +784,20 @@ EXPORT_SYMBOL(scsi_release_buffers);
* in req->data_len and req->next_rq->data_len. The upper-layer driver can
* decide what to do with this information.
*/
-void scsi_end_bidi_request(struct scsi_cmnd *cmd)
+static void scsi_end_blk_request(struct scsi_cmnd *cmd)
{
struct request *req = cmd->request;
unsigned int dlen = req->data_len;
- unsigned int next_dlen = req->next_rq->data_len;
+ unsigned int next_dlen;
- req->data_len = scsi_out(cmd)->resid;
- req->next_rq->data_len = scsi_in(cmd)->resid;
+ if (blk_bidi_rq(req)) {
+ next_dlen = req->next_rq->data_len;
+ req->data_len = scsi_out(cmd)->resid;
+ req->next_rq->data_len = scsi_in(cmd)->resid;
+ } else {
+ next_dlen = 0;
+ req->data_len = scsi_get_resid(cmd);
+ }
/* The req and req->next_rq have not been completed */
BUG_ON(blk_end_bidi_request(req, 0, dlen, next_dlen));
@@ -866,15 +872,11 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
req->sense_len = len;
}
}
- if (scsi_bidi_cmnd(cmd)) {
- /* will also release_buffers */
- scsi_end_bidi_request(cmd);
- return;
- }
- req->data_len = scsi_get_resid(cmd);
+ /* will also release_buffers */
+ scsi_end_blk_request(cmd);
+ return;
}
- BUG_ON(blk_bidi_rq(req)); /* bidi not support for !blk_pc_request yet */
scsi_release_buffers(cmd);
/*
--
1.5.3.3
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-12 16:09 ` Boaz Harrosh
@ 2008-03-14 13:11 ` Michael Reed
2008-03-18 16:12 ` Michael Reed
0 siblings, 1 reply; 18+ messages in thread
From: Michael Reed @ 2008-03-14 13:11 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: linux-scsi
Boaz Harrosh wrote:
<snip>
>>
>>> Just to demonstrate what I mean a patch is attached. Just as an RFC, totally
>>> untested.
>> I can try this out and see what happens.
>>
>>
> Will not compile here is a cleaner one
Still in my queue. Hopefully I'll get to poke at this today.
Mike
>
> ---
> From: Boaz Harrosh <bharrosh@panasas.com>
> Date: Wed, 12 Mar 2008 13:18:49 +0200
> Subject: [PATCH] scsi: Always complete BLOCK_PC commands
>
> Current code, in some IO combinations could wrongly retry
> a BLOCK_PC command in chunks. This was never intended.
> Fix it that BLOCK_PC will always complete atomically
>
> Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
> ---
> drivers/scsi/scsi_lib.c | 24 +++++++++++++-----------
> 1 files changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index ba21d97..4b8b57c 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -784,14 +784,20 @@ EXPORT_SYMBOL(scsi_release_buffers);
> * in req->data_len and req->next_rq->data_len. The upper-layer driver can
> * decide what to do with this information.
> */
> -void scsi_end_bidi_request(struct scsi_cmnd *cmd)
> +static void scsi_end_blk_request(struct scsi_cmnd *cmd)
> {
> struct request *req = cmd->request;
> unsigned int dlen = req->data_len;
> - unsigned int next_dlen = req->next_rq->data_len;
> + unsigned int next_dlen;
>
> - req->data_len = scsi_out(cmd)->resid;
> - req->next_rq->data_len = scsi_in(cmd)->resid;
> + if (blk_bidi_rq(req)) {
> + next_dlen = req->next_rq->data_len;
> + req->data_len = scsi_out(cmd)->resid;
> + req->next_rq->data_len = scsi_in(cmd)->resid;
> + } else {
> + next_dlen = 0;
> + req->data_len = scsi_get_resid(cmd);
> + }
>
> /* The req and req->next_rq have not been completed */
> BUG_ON(blk_end_bidi_request(req, 0, dlen, next_dlen));
> @@ -866,15 +872,11 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
> req->sense_len = len;
> }
> }
> - if (scsi_bidi_cmnd(cmd)) {
> - /* will also release_buffers */
> - scsi_end_bidi_request(cmd);
> - return;
> - }
> - req->data_len = scsi_get_resid(cmd);
> + /* will also release_buffers */
> + scsi_end_blk_request(cmd);
> + return;
> }
>
> - BUG_ON(blk_bidi_rq(req)); /* bidi not support for !blk_pc_request yet */
> scsi_release_buffers(cmd);
>
> /*
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-11 22:10 [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24 Michael Reed
2008-03-12 10:46 ` Boaz Harrosh
@ 2008-03-17 18:08 ` Mike Christie
2008-03-18 0:48 ` FUJITA Tomonori
1 sibling, 1 reply; 18+ messages in thread
From: Mike Christie @ 2008-03-17 18:08 UTC (permalink / raw)
To: Michael Reed; +Cc: Douglas Gilbert, linux-scsi, Jeremy Higdon, James Bottomley
Michael Reed wrote:
> - ++blk_size; /* don't know why */
> -/* round request up to next highest SG_SECTOR_SZ byte boundary */
I think we can remove this code. This was asked before, and here is
Doug's reply:
http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg11757.html
It was probaly due to some weirdness in that the scatterlist that sg.c
made used to be sent directly to the LLD (now it is only used to
hold/organize the pages/segments that the sg and st driver manages in
their internal reserves), or maybe it had something to do with that and
dma alignment problems or something. I really have no idea, but the
block layer SG IO code has not been rounding up in its indirect path and
it has been fine.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-17 18:08 ` Mike Christie
@ 2008-03-18 0:48 ` FUJITA Tomonori
0 siblings, 0 replies; 18+ messages in thread
From: FUJITA Tomonori @ 2008-03-18 0:48 UTC (permalink / raw)
To: michaelc; +Cc: mdr, dougg, linux-scsi, jeremy, James.Bottomley, tomof
On Mon, 17 Mar 2008 13:08:39 -0500
Mike Christie <michaelc@cs.wisc.edu> wrote:
> Michael Reed wrote:
> > - ++blk_size; /* don't know why */
> > -/* round request up to next highest SG_SECTOR_SZ byte boundary */
>
> I think we can remove this code. This was asked before, and here is
> Doug's reply:
> http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg11757.html
>
> It was probaly due to some weirdness in that the scatterlist that sg.c
> made used to be sent directly to the LLD (now it is only used to
> hold/organize the pages/segments that the sg and st driver manages in
> their internal reserves), or maybe it had something to do with that and
> dma alignment problems or something. I really have no idea, but the
> block layer SG IO code has not been rounding up in its indirect path and
> it has been fine.
The block layer (blk_rq_map_user) does padding for LLDs, I guess.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-14 13:11 ` Michael Reed
@ 2008-03-18 16:12 ` Michael Reed
2008-03-18 16:20 ` Boaz Harrosh
0 siblings, 1 reply; 18+ messages in thread
From: Michael Reed @ 2008-03-18 16:12 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: linux-scsi
Michael Reed wrote:
>
> Boaz Harrosh wrote:
> <snip>
>>>> Just to demonstrate what I mean a patch is attached. Just as an RFC, totally
>>>> untested.
>>> I can try this out and see what happens.
>>>
>>>
>> Will not compile here is a cleaner one
>
> Still in my queue. Hopefully I'll get to poke at this today.
Patch compiles cleanly and appears to have no effect on the misc.
sg_* commands I've executed including sg_dd, sg_inq, sg_luns, sg_readcap.
Mike
>
> Mike
>
>> ---
>> From: Boaz Harrosh <bharrosh@panasas.com>
>> Date: Wed, 12 Mar 2008 13:18:49 +0200
>> Subject: [PATCH] scsi: Always complete BLOCK_PC commands
>>
>> Current code, in some IO combinations could wrongly retry
>> a BLOCK_PC command in chunks. This was never intended.
>> Fix it that BLOCK_PC will always complete atomically
>>
>> Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
>> ---
>> drivers/scsi/scsi_lib.c | 24 +++++++++++++-----------
>> 1 files changed, 13 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index ba21d97..4b8b57c 100644
>> --- a/drivers/scsi/scsi_lib.c
>> +++ b/drivers/scsi/scsi_lib.c
>> @@ -784,14 +784,20 @@ EXPORT_SYMBOL(scsi_release_buffers);
>> * in req->data_len and req->next_rq->data_len. The upper-layer driver can
>> * decide what to do with this information.
>> */
>> -void scsi_end_bidi_request(struct scsi_cmnd *cmd)
>> +static void scsi_end_blk_request(struct scsi_cmnd *cmd)
>> {
>> struct request *req = cmd->request;
>> unsigned int dlen = req->data_len;
>> - unsigned int next_dlen = req->next_rq->data_len;
>> + unsigned int next_dlen;
>>
>> - req->data_len = scsi_out(cmd)->resid;
>> - req->next_rq->data_len = scsi_in(cmd)->resid;
>> + if (blk_bidi_rq(req)) {
>> + next_dlen = req->next_rq->data_len;
>> + req->data_len = scsi_out(cmd)->resid;
>> + req->next_rq->data_len = scsi_in(cmd)->resid;
>> + } else {
>> + next_dlen = 0;
>> + req->data_len = scsi_get_resid(cmd);
>> + }
>>
>> /* The req and req->next_rq have not been completed */
>> BUG_ON(blk_end_bidi_request(req, 0, dlen, next_dlen));
>> @@ -866,15 +872,11 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
>> req->sense_len = len;
>> }
>> }
>> - if (scsi_bidi_cmnd(cmd)) {
>> - /* will also release_buffers */
>> - scsi_end_bidi_request(cmd);
>> - return;
>> - }
>> - req->data_len = scsi_get_resid(cmd);
>> + /* will also release_buffers */
>> + scsi_end_blk_request(cmd);
>> + return;
>> }
>>
>> - BUG_ON(blk_bidi_rq(req)); /* bidi not support for !blk_pc_request yet */
>> scsi_release_buffers(cmd);
>>
>> /*
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-18 16:12 ` Michael Reed
@ 2008-03-18 16:20 ` Boaz Harrosh
2008-03-18 16:52 ` Michael Reed
2008-03-18 17:13 ` Michael Reed
0 siblings, 2 replies; 18+ messages in thread
From: Boaz Harrosh @ 2008-03-18 16:20 UTC (permalink / raw)
To: Michael Reed; +Cc: linux-scsi
On Tue, Mar 18 2008 at 18:12 +0200, Michael Reed <mdr@sgi.com> wrote:
>
> Michael Reed wrote:
>> Boaz Harrosh wrote:
>> <snip>
>>>>> Just to demonstrate what I mean a patch is attached. Just as an RFC, totally
>>>>> untested.
>>>> I can try this out and see what happens.
>>>>
>>>>
>>> Will not compile here is a cleaner one
>> Still in my queue. Hopefully I'll get to poke at this today.
>
> Patch compiles cleanly and appears to have no effect on the misc.
> sg_* commands I've executed including sg_dd, sg_inq, sg_luns, sg_readcap.
>
> Mike
>
>> Mike
>>
<patch sniped>
If you remove the original fix to sg.c
([PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24)
and apply this patch, does it solve your original infinite loop?
Thanks
Boaz
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-18 16:20 ` Boaz Harrosh
@ 2008-03-18 16:52 ` Michael Reed
2008-03-18 17:19 ` Boaz Harrosh
2008-03-18 17:13 ` Michael Reed
1 sibling, 1 reply; 18+ messages in thread
From: Michael Reed @ 2008-03-18 16:52 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: linux-scsi
Boaz Harrosh wrote:
> On Tue, Mar 18 2008 at 18:12 +0200, Michael Reed <mdr@sgi.com> wrote:
>> Michael Reed wrote:
>>> Boaz Harrosh wrote:
>>> <snip>
>>>>>> Just to demonstrate what I mean a patch is attached. Just as an RFC, totally
>>>>>> untested.
>>>>> I can try this out and see what happens.
>>>>>
>>>>>
>>>> Will not compile here is a cleaner one
>>> Still in my queue. Hopefully I'll get to poke at this today.
>> Patch compiles cleanly and appears to have no effect on the misc.
>> sg_* commands I've executed including sg_dd, sg_inq, sg_luns, sg_readcap.
>>
>> Mike
>>
>>> Mike
>>>
> <patch sniped>
>
> If you remove the original fix to sg.c
> ([PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24)
>
> and apply this patch, does it solve your original infinite loop?
Unfortunately, the infinite loop only occurred at 2.6.24. I'll see if
I can break the current rc by removing some known fixes.
Care to gen a patch for 2.6.24?
Mike
>
> Thanks
> Boaz
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-18 16:20 ` Boaz Harrosh
2008-03-18 16:52 ` Michael Reed
@ 2008-03-18 17:13 ` Michael Reed
2008-03-18 18:23 ` Boaz Harrosh
1 sibling, 1 reply; 18+ messages in thread
From: Michael Reed @ 2008-03-18 17:13 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: linux-scsi
Boaz Harrosh wrote:
> On Tue, Mar 18 2008 at 18:12 +0200, Michael Reed <mdr@sgi.com> wrote:
>> Michael Reed wrote:
>>> Boaz Harrosh wrote:
>>> <snip>
>>>>>> Just to demonstrate what I mean a patch is attached. Just as an RFC, totally
>>>>>> untested.
>>>>> I can try this out and see what happens.
>>>>>
>>>>>
>>>> Will not compile here is a cleaner one
>>> Still in my queue. Hopefully I'll get to poke at this today.
>> Patch compiles cleanly and appears to have no effect on the misc.
>> sg_* commands I've executed including sg_dd, sg_inq, sg_luns, sg_readcap.
>>
>> Mike
>>
>>> Mike
>>>
> <patch sniped>
>
> If you remove the original fix to sg.c
> ([PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24)
>
> and apply this patch, does it solve your original infinite loop?
By removing a fix in scsi_req_map_sg and forcing sg_start_req() to always
call sg_build_indirect() (and not applying my fix to sg.c) I'm able to
reproduce the problem without crashing the system.
With your patch applied to 2.6.25-rc4-git3 I get this.... (The mptscsih_qcmd
output is evidence that the condition was generated which would have caused
the infinite loop.)
mptscsih_qcmd: cmd e0000070845e0f00 / 18, dd 2, sg_count 1, sglist e00000709a785600, bufflen 255, bi_size 512
mptscsih_qcmd: cmd e0000070845e1500 / 18, dd 2, sg_count 1, sglist e00000709a785500, bufflen 255, bi_size 512
Pid: 0, CPU 10, comm: swapper
psr : 0000101008026038 ifs : 800000000000058f ip : [<a000000100554a00>] Not tainted (2.6.25-rc4-git3)
ip is at scsi_io_completion+0x2e0/0x900
unat: 0000000000000000 pfs : 000000000000058f rsc : 0000000000000003
rnat: 0bad0bad0baea565 bsps: a000000100094fe0 pr : 0bad0bad0bae9965
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c0270033f
csd : 0000000000000000 ssd : 0000000000000000
b0 : a000000100554a00 b6 : a000000100090aa0 b7 : a0000001000a2640
f6 : 1003e000000000000b080 f7 : 1003e0000000000000000
f8 : 1003e00000000a066a81a f9 : 1003e000000080dc98009
f10 : 1003e0bd8b82c4612e8ea f11 : 1003e0000000000000005
r1 : a000000100eee010 r2 : ffffffffffff9400 r3 : a000000100c89348
r8 : 000000000000002e r9 : a000000100c89348 r10 : a000000100d58f30
r11 : e000007082368d54 r12 : e00000708236fb90 r13 : e000007082368000
r14 : 0000000000004000 r15 : a000000100c89348 r16 : a000000100c89330
r17 : e0000170bd607e18 r18 : 0000000000004000 r19 : 0000000000000000
r20 : 0000000000004000 r21 : e000007082368d50 r22 : 0000000000000000
r23 : 0000000000000001 r24 : 0000000000000000 r25 : 0000000000000000
r26 : 0000000000000002 r27 : 0000000000000000 r28 : 000000000000000a
r29 : e000007082368d54 r30 : a000000100ce4ef8 r31 : a000000100ce4e98
Call Trace:
[<a0000001000128a0>] show_stack+0x40/0xa0
sp=e00000708236f760 bsp=e000007082369178
[<a0000001000131b0>] show_regs+0x850/0x8a0
sp=e00000708236f930 bsp=e000007082369120
[<a000000100033d10>] die+0x1b0/0x2e0
sp=e00000708236f930 bsp=e0000070823690d8
[<a000000100033e90>] die_if_kernel+0x50/0x80
sp=e00000708236f930 bsp=e0000070823690a8
[<a0000001000355f0>] ia64_bad_break+0x230/0x520
sp=e00000708236f930 bsp=e000007082369080
[<a00000010000a260>] ia64_leave_kernel+0x0/0x270
sp=e00000708236f9c0 bsp=e000007082369080
[<a000000100554a00>] scsi_io_completion+0x2e0/0x900
sp=e00000708236fb90 bsp=e000007082369008
[<a000000100546570>] scsi_finish_command+0x1d0/0x200
sp=e00000708236fba0 bsp=e000007082368fd0
Entering kdb (current=0xe000007082368000, pid 0) on processor 10 Oops: <NULL>
due to oops @ 0xa000000100554a00
psr: 0x0000101008026038 ifs: 0x800000000000058f ip: 0xa000000100554a00
unat: 0x0000000000000000 pfs: 0x000000000000058f rsc: 0x0000000000000003
rnat: 0x0bad0bad0baea565 bsps: 0xa000000100094fe0 pr: 0x0bad0bad0bae9965
ldrs: 0x0000000000000000 ccv: 0x0000000000000000 fpsr: 0x0009804c0270033f
b0: 0xa000000100554a00 b6: 0xa000000100090aa0 b7: 0xa0000001000a2640
r1: 0xa000000100eee010 r2: 0xffffffffffff9400 r3: 0xa000000100c89348
r8: 0x000000000000002e r9: 0xa000000100c89348 r10: 0xa000000100d58f30
r11: 0xe000007082368d54 r12: 0xe00000708236fb90 r13: 0xe000007082368000
r14: 0x0000000000004000 r15: 0xa000000100c89348 r16: 0xa000000100c89330
r17: 0xe0000170bd607e18 r18: 0x0000000000004000 r19: 0x0000000000000000
r20: 0x0000000000004000 r21: 0xe000007082368d50 r22: 0x0000000000000000
r23: 0x0000000000000001 r24: 0x0000000000000000 r25: 0x0000000000000000
r26: 0x0000000000000002 r27: 0x0000000000000000 r28: 0x000000000000000a
r29: 0xe000007082368d54 r30: 0xa000000100ce4ef8 r31: 0xa000000100ce4e98
®s = e00000708236f9d0
[10]kdb> bt
Stack traceback for pid 0
0xe000007082368000 0 1 1 10 R 0xe0000070823683b0 *swapper
0xa000000100554a00 scsi_io_completion+0x2e0
args (0xe0000070845e0600, 0xff, 0x0, 0xe0000070845ddf38, 0x0, 0x0, 0xe000027085dfd368, 0xff, 0xa000000100546570)
0xa000000100546570 scsi_finish_command+0x1d0
args (0xe0000070845e0600, 0xe000027085de5140, 0xe000027085de7800, 0xa0000001005556b0, 0x30a, 0xa000000100eee010)
0xa0000001005556b0 scsi_softirq_done+0x270
args (0xe0000070845e0600, 0x2002, 0x0, 0xa0000001003aba60, 0x184, 0xe0000070845e0718)
0xa0000001003aba60 blk_done_softirq+0x140
args (0xa0000001000b60b0, 0x790, 0xa000000100eee010)
0xa0000001000b60b0 __do_softirq+0xf0
args (0xe0000270822784d0, 0xe000027082278480, 0xffffffff, 0xe000027085e0d880, 0xa00000010010af80, 0x40b, 0xa000000100eee010, 0xa00000010010aba0, 0x1)
0xa0000001000b6270 do_softirq+0x70
args (0xa000000100bb8708, 0x0, 0xa00000010000ff70, 0x30a, 0xa000000100eee010, 0x218, 0xa000000100d0aac8, 0xa00000010010b040, 0x1008022038)
0xa0000001000b6560 irq_exit+0x80
args (0xa00000010000fff0, 0x30a, 0x0)
0xa00000010000fff0 ia64_handle_irq+0x2f0
args (0xf, 0x0, 0x0, 0xa00000010000a260, 0x2, 0xa000000100eee010)
0xa00000010000a260 ia64_leave_kernel
args (0xf, 0x0)
0xa000000100013550 default_idle+0x110
args (0xe00000708236fdc0, 0xa0000001000125e0, 0x40c, 0x10)
0xa0000001000125e0 cpu_idle+0x1e0
args (0xa000000100940330, 0xa000000100d0aa48, 0xa, 0xa000000100dc69e8, 0xa0000001009a3b50, 0x40b, 0xa000000100eee010, 0xbad0bad0badaa65)
0xa0000001009a3b50 start_secondary+0x4d0
args (0x20000500, 0x6e65470020000504, 0x400, 0xffffffff00, 0x3ff, 0xa000000100769fa0, 0x0, 0x3)
0xa000000100769fa0 __kprobes_text_end+0x340
Mike
>
> Thanks
> Boaz
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-18 16:52 ` Michael Reed
@ 2008-03-18 17:19 ` Boaz Harrosh
2008-03-19 15:57 ` Michael Reed
0 siblings, 1 reply; 18+ messages in thread
From: Boaz Harrosh @ 2008-03-18 17:19 UTC (permalink / raw)
To: Michael Reed; +Cc: linux-scsi
On Tue, Mar 18 2008 at 18:52 +0200, Michael Reed <mdr@sgi.com> wrote:
>
> Boaz Harrosh wrote:
>> On Tue, Mar 18 2008 at 18:12 +0200, Michael Reed <mdr@sgi.com> wrote:
>>> Michael Reed wrote:
>>>> Boaz Harrosh wrote:
>>>> <snip>
>>>>>>> Just to demonstrate what I mean a patch is attached. Just as an RFC, totally
>>>>>>> untested.
>>>>>> I can try this out and see what happens.
>>>>>>
>>>>>>
>>>>> Will not compile here is a cleaner one
>>>> Still in my queue. Hopefully I'll get to poke at this today.
>>> Patch compiles cleanly and appears to have no effect on the misc.
>>> sg_* commands I've executed including sg_dd, sg_inq, sg_luns, sg_readcap.
>>>
>>> Mike
>>>
>>>> Mike
>>>>
>> <patch sniped>
>>
>> If you remove the original fix to sg.c
>> ([PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24)
>>
>> and apply this patch, does it solve your original infinite loop?
>
> Unfortunately, the infinite loop only occurred at 2.6.24. I'll see if
> I can break the current rc by removing some known fixes.
>
> Care to gen a patch for 2.6.24?
>
> Mike
>
>> Thanks
>> Boaz
>>
here is the same principle on Linux 2.6.24
---
[PATCH] scsi: Always complete BLOCK_PC commands
Current code, in some IO combinations could wrongly retry
a BLOCK_PC command in chunks. This was never intended.
Fix it that BLOCK_PC will always complete atomically
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
---
git-diff --stat -p
drivers/scsi/scsi_lib.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index a9ac5b1..ae32012 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -966,7 +966,16 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
req->sense_len = len;
}
}
+ good_bytes = req->data_len;
req->data_len = cmd->resid;
+retry_end_req:
+ if (scsi_end_request(cmd, 1, good_bytes, 0) != NULL) {
+ WARN_ON(1);
+ good_bytes = req->data_len;
+ goto retry_end_req;
+ }
+
+ return;
}
/*
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-18 17:13 ` Michael Reed
@ 2008-03-18 18:23 ` Boaz Harrosh
2008-03-18 19:51 ` Michael Reed
0 siblings, 1 reply; 18+ messages in thread
From: Boaz Harrosh @ 2008-03-18 18:23 UTC (permalink / raw)
To: Michael Reed; +Cc: linux-scsi
On Tue, Mar 18 2008 at 19:13 +0200, Michael Reed <mdr@sgi.com> wrote:
>
> Boaz Harrosh wrote:
>> On Tue, Mar 18 2008 at 18:12 +0200, Michael Reed <mdr@sgi.com> wrote:
>>> Michael Reed wrote:
>>>> Boaz Harrosh wrote:
>>>> <snip>
>>>>>>> Just to demonstrate what I mean a patch is attached. Just as an RFC, totally
>>>>>>> untested.
>>>>>> I can try this out and see what happens.
>>>>>>
>>>>>>
>>>>> Will not compile here is a cleaner one
>>>> Still in my queue. Hopefully I'll get to poke at this today.
>>> Patch compiles cleanly and appears to have no effect on the misc.
>>> sg_* commands I've executed including sg_dd, sg_inq, sg_luns, sg_readcap.
>>>
>>> Mike
>>>
>>>> Mike
>>>>
>> <patch sniped>
>>
>> If you remove the original fix to sg.c
>> ([PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24)
>>
>> and apply this patch, does it solve your original infinite loop?
>
> By removing a fix in scsi_req_map_sg and forcing sg_start_req() to always
> call sg_build_indirect() (and not applying my fix to sg.c) I'm able to
> reproduce the problem without crashing the system.
>
> With your patch applied to 2.6.25-rc4-git3 I get this.... (The mptscsih_qcmd
> output is evidence that the condition was generated which would have caused
> the infinite loop.)
>
>
> mptscsih_qcmd: cmd e0000070845e0f00 / 18, dd 2, sg_count 1, sglist e00000709a785600, bufflen 255, bi_size 512
> mptscsih_qcmd: cmd e0000070845e1500 / 18, dd 2, sg_count 1, sglist e00000709a785500, bufflen 255, bi_size 512
> Pid: 0, CPU 10, comm: swapper
> psr : 0000101008026038 ifs : 800000000000058f ip : [<a000000100554a00>] Not tainted (2.6.25-rc4-git3)
> ip is at scsi_io_completion+0x2e0/0x900
> unat: 0000000000000000 pfs : 000000000000058f rsc : 0000000000000003
> rnat: 0bad0bad0baea565 bsps: a000000100094fe0 pr : 0bad0bad0bae9965
> ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c0270033f
> csd : 0000000000000000 ssd : 0000000000000000
> b0 : a000000100554a00 b6 : a000000100090aa0 b7 : a0000001000a2640
> f6 : 1003e000000000000b080 f7 : 1003e0000000000000000
> f8 : 1003e00000000a066a81a f9 : 1003e000000080dc98009
> f10 : 1003e0bd8b82c4612e8ea f11 : 1003e0000000000000005
> r1 : a000000100eee010 r2 : ffffffffffff9400 r3 : a000000100c89348
> r8 : 000000000000002e r9 : a000000100c89348 r10 : a000000100d58f30
> r11 : e000007082368d54 r12 : e00000708236fb90 r13 : e000007082368000
> r14 : 0000000000004000 r15 : a000000100c89348 r16 : a000000100c89330
> r17 : e0000170bd607e18 r18 : 0000000000004000 r19 : 0000000000000000
> r20 : 0000000000004000 r21 : e000007082368d50 r22 : 0000000000000000
> r23 : 0000000000000001 r24 : 0000000000000000 r25 : 0000000000000000
> r26 : 0000000000000002 r27 : 0000000000000000 r28 : 000000000000000a
> r29 : e000007082368d54 r30 : a000000100ce4ef8 r31 : a000000100ce4e98
>
> Call Trace:
> [<a0000001000128a0>] show_stack+0x40/0xa0
> sp=e00000708236f760 bsp=e000007082369178
> [<a0000001000131b0>] show_regs+0x850/0x8a0
> sp=e00000708236f930 bsp=e000007082369120
> [<a000000100033d10>] die+0x1b0/0x2e0
> sp=e00000708236f930 bsp=e0000070823690d8
> [<a000000100033e90>] die_if_kernel+0x50/0x80
> sp=e00000708236f930 bsp=e0000070823690a8
> [<a0000001000355f0>] ia64_bad_break+0x230/0x520
> sp=e00000708236f930 bsp=e000007082369080
> [<a00000010000a260>] ia64_leave_kernel+0x0/0x270
> sp=e00000708236f9c0 bsp=e000007082369080
> [<a000000100554a00>] scsi_io_completion+0x2e0/0x900
> sp=e00000708236fb90 bsp=e000007082369008
> [<a000000100546570>] scsi_finish_command+0x1d0/0x200
> sp=e00000708236fba0 bsp=e000007082368fd0
>
> Entering kdb (current=0xe000007082368000, pid 0) on processor 10 Oops: <NULL>
> due to oops @ 0xa000000100554a00
> psr: 0x0000101008026038 ifs: 0x800000000000058f ip: 0xa000000100554a00
> unat: 0x0000000000000000 pfs: 0x000000000000058f rsc: 0x0000000000000003
> rnat: 0x0bad0bad0baea565 bsps: 0xa000000100094fe0 pr: 0x0bad0bad0bae9965
> ldrs: 0x0000000000000000 ccv: 0x0000000000000000 fpsr: 0x0009804c0270033f
> b0: 0xa000000100554a00 b6: 0xa000000100090aa0 b7: 0xa0000001000a2640
> r1: 0xa000000100eee010 r2: 0xffffffffffff9400 r3: 0xa000000100c89348
> r8: 0x000000000000002e r9: 0xa000000100c89348 r10: 0xa000000100d58f30
> r11: 0xe000007082368d54 r12: 0xe00000708236fb90 r13: 0xe000007082368000
> r14: 0x0000000000004000 r15: 0xa000000100c89348 r16: 0xa000000100c89330
> r17: 0xe0000170bd607e18 r18: 0x0000000000004000 r19: 0x0000000000000000
> r20: 0x0000000000004000 r21: 0xe000007082368d50 r22: 0x0000000000000000
> r23: 0x0000000000000001 r24: 0x0000000000000000 r25: 0x0000000000000000
> r26: 0x0000000000000002 r27: 0x0000000000000000 r28: 0x000000000000000a
> r29: 0xe000007082368d54 r30: 0xa000000100ce4ef8 r31: 0xa000000100ce4e98
> ®s = e00000708236f9d0
>
> [10]kdb> bt
> Stack traceback for pid 0
> 0xe000007082368000 0 1 1 10 R 0xe0000070823683b0 *swapper
> 0xa000000100554a00 scsi_io_completion+0x2e0
> args (0xe0000070845e0600, 0xff, 0x0, 0xe0000070845ddf38, 0x0, 0x0, 0xe000027085dfd368, 0xff, 0xa000000100546570)
> 0xa000000100546570 scsi_finish_command+0x1d0
> args (0xe0000070845e0600, 0xe000027085de5140, 0xe000027085de7800, 0xa0000001005556b0, 0x30a, 0xa000000100eee010)
> 0xa0000001005556b0 scsi_softirq_done+0x270
> args (0xe0000070845e0600, 0x2002, 0x0, 0xa0000001003aba60, 0x184, 0xe0000070845e0718)
> 0xa0000001003aba60 blk_done_softirq+0x140
> args (0xa0000001000b60b0, 0x790, 0xa000000100eee010)
> 0xa0000001000b60b0 __do_softirq+0xf0
> args (0xe0000270822784d0, 0xe000027082278480, 0xffffffff, 0xe000027085e0d880, 0xa00000010010af80, 0x40b, 0xa000000100eee010, 0xa00000010010aba0, 0x1)
> 0xa0000001000b6270 do_softirq+0x70
> args (0xa000000100bb8708, 0x0, 0xa00000010000ff70, 0x30a, 0xa000000100eee010, 0x218, 0xa000000100d0aac8, 0xa00000010010b040, 0x1008022038)
> 0xa0000001000b6560 irq_exit+0x80
> args (0xa00000010000fff0, 0x30a, 0x0)
> 0xa00000010000fff0 ia64_handle_irq+0x2f0
> args (0xf, 0x0, 0x0, 0xa00000010000a260, 0x2, 0xa000000100eee010)
> 0xa00000010000a260 ia64_leave_kernel
> args (0xf, 0x0)
> 0xa000000100013550 default_idle+0x110
> args (0xe00000708236fdc0, 0xa0000001000125e0, 0x40c, 0x10)
> 0xa0000001000125e0 cpu_idle+0x1e0
> args (0xa000000100940330, 0xa000000100d0aa48, 0xa, 0xa000000100dc69e8, 0xa0000001009a3b50, 0x40b, 0xa000000100eee010, 0xbad0bad0badaa65)
> 0xa0000001009a3b50 start_secondary+0x4d0
> args (0x20000500, 0x6e65470020000504, 0x400, 0xffffffff00, 0x3ff, 0xa000000100769fa0, 0x0, 0x3)
> 0xa000000100769fa0 __kprobes_text_end+0x340
>
> Mike
>
I don't understand is that a NULL dereference do to my patch? did you manage to find
what is the line of code that dereferences the NULL pointer.
Thanks
Boaz
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-18 18:23 ` Boaz Harrosh
@ 2008-03-18 19:51 ` Michael Reed
2008-03-19 9:49 ` Boaz Harrosh
0 siblings, 1 reply; 18+ messages in thread
From: Michael Reed @ 2008-03-18 19:51 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: linux-scsi
Boaz Harrosh wrote:
> On Tue, Mar 18 2008 at 19:13 +0200, Michael Reed <mdr@sgi.com> wrote:
>> Boaz Harrosh wrote:
>>> On Tue, Mar 18 2008 at 18:12 +0200, Michael Reed <mdr@sgi.com> wrote:
>>>> Michael Reed wrote:
>>>>> Boaz Harrosh wrote:
>>>>> <snip>
>>>>>>>> Just to demonstrate what I mean a patch is attached. Just as an RFC, totally
>>>>>>>> untested.
>>>>>>> I can try this out and see what happens.
>>>>>>>
>>>>>>>
>>>>>> Will not compile here is a cleaner one
>>>>> Still in my queue. Hopefully I'll get to poke at this today.
>>>> Patch compiles cleanly and appears to have no effect on the misc.
>>>> sg_* commands I've executed including sg_dd, sg_inq, sg_luns, sg_readcap.
>>>>
>>>> Mike
>>>>
>>>>> Mike
>>>>>
>>> <patch snipped>
>>>
>>> If you remove the original fix to sg.c
>>> ([PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24)
>>>
>>> and apply this patch, does it solve your original infinite loop?
>> By removing a fix in scsi_req_map_sg and forcing sg_start_req() to always
>> call sg_build_indirect() (and not applying my fix to sg.c) I'm able to
>> reproduce the problem without crashing the system.
>>
>> With your patch applied to 2.6.25-rc4-git3 I get this.... (The mptscsih_qcmd
>> output is evidence that the condition was generated which would have caused
>> the infinite loop.)
>>
>>
< snip backtrace >
>>
>> Mike
>>
>
> I don't understand is that a NULL dereference due to my patch? did you manage to find
> what is the line of code that dereferences the NULL pointer.
I'm going to say "yes", it's due to your patch. It's happened twice in
a row.
Disabling inline functions gets me a better backtrace. And dumping
the dmesg buffer I see the BUG in scsi_end_blk_request().
BUG_ON(blk_end_bidi_request(req, 0, dlen, next_dlen));
I guess this is what I would expect to happen.
blk_end_bidi_request ->
blk_end_io ->
__end_that_request_first
__end_that_request_first returns "1" indicating that the
request wasn't completely finished.
I guess it could be argued that this really is a bug and that the
buffer length and bi_size should always be the same. Would
the same thing happen if a command returned a residual or
an i/o error?
<4>mptscsih_qcmd: cmd e00000708c2f6700 / 18, dd 2, sg_count 1, sglist e000007000080d00, bufflen 255, bi_size 512
<4>kernel BUG at drivers/scsi/scsi_lib.c:809! (I have other changes in this file.)
<4>swapper[0]: bugcheck! 0 [1]
<4>Modules linked in: ipv6 mptfc mptspi sg mptsas mptscsih mptbase qla1280
<4>
<4>Pid: 0, CPU 10, comm: swapper
<4>psr : 0000101008026038 ifs : 8000000000000208 ip : [<a00000010057aaf0>] Not tainted (2.6.25-rc4-git3)
<4>ip is at scsi_end_blk_request+0x150/0x1e0
<4>unat: 0000000000000000 pfs : 0000000000000208 rsc : 0000000000000003
<4>rnat: 0bad0bad0bae2965 bsps: a0000001000956c0 pr : 0bad0bad0bae9965
<4>ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c0270033f
<4>csd : 0000000000000000 ssd : 0000000000000000
<4>b0 : a00000010057aaf0 b6 : a00000010009d740 b7 : a00000010009daa0
<4>f6 : 1003e000000000000b080 f7 : 1003e0a7c5ac471b47843
<4>f8 : 1003e00000000a066a81a f9 : 1003e00000007fbf88741
<4>f10 : 1003e00aef7b933e6649a f11 : 1003e0000000000000005
<4>r1 : a000000100f4e010 r2 : ffffffffffff9400 r3 : a000000100ce9348
<4>r8 : 000000000000002e r9 : a000000100ce9348 r10 : a000000100db9030
<4>r11 : e000027082200d54 r12 : e000027082207b90 r13 : e000027082200000
<4>r14 : 0000000000004000 r15 : a000000100ce9348 r16 : a000000100ce9330
<4>r17 : e0000270a8437e18 r18 : 0000000000000000 r19 : 0000000000000000
<4>r20 : 0000000000000000 r21 : e000027082200d50 r22 : 0000000000000000
<4>r23 : 0000000000000001 r24 : 0000000000000000 r25 : 0000000000000000
<4>r26 : 0000000000000002 r27 : 0000000000004000 r28 : 0000000000004000
<4>r29 : e000027082200d54 r30 : a000000100d44ef8 r31 : a000000100d44e98
<4>
<4>Call Trace:
<4> [<a000000100012e60>] show_stack+0x40/0xa0
<4> sp=e000027082207760 bsp=e000027082201170
<4> [<a000000100013710>] show_regs+0x850/0x8a0
<4> sp=e000027082207930 bsp=e000027082201118
<4> [<a0000001000351d0>] die+0x1b0/0x2e0
<4> sp=e000027082207930 bsp=e0000270822010d0
<4> [<a000000100035350>] die_if_kernel+0x50/0x80
<4> sp=e000027082207930 bsp=e0000270822010a0
<4> [<a000000100036350>] ia64_bad_break+0x230/0x520
<4> sp=e000027082207930 bsp=e000027082201078
<4> [<a00000010000a320>] ia64_leave_kernel+0x0/0x270
<4> sp=e0000270822079c0 bsp=e000027082201078
<4> [<a00000010057aaf0>] scsi_end_blk_request+0x150/0x1e0
<4> sp=e000027082207b90 bsp=e000027082201038
<4> [<a00000010057af60>] scsi_io_completion+0x1c0/0x780
<4> sp=e000027082207b90 bsp=e000027082200fd8
<4> [<a00000010056ba90>] scsi_finish_command+0x1d0/0x200
<4> sp=e000027082207ba0 bsp=e000027082200fa8
<4> [<a00000010057b8f0>] scsi_softirq_done+0x270/0x2a0
<4> sp=e000027082207ba0 bsp=e000027082200f78
<4> [<a0000001003c6480>] blk_done_softirq+0x140/0x1a0
<4> sp=e000027082207bb0 bsp=e000027082200f60
<4> [<a0000001000be170>] __do_softirq+0xf0/0x240
<4> sp=e000027082207bc0 bsp=e000027082200ee8
<4> [<a0000001000be330>] do_softirq+0x70/0xc0
<4> sp=e000027082207bc0 bsp=e000027082200e88
<4> [<a0000001000be620>] irq_exit+0x80/0xa0
<4> sp=e000027082207bc0 bsp=e000027082200e70
<4> [<a00000010000f530>] ia64_handle_irq+0x2f0/0x320
<4> sp=e000027082207bc0 bsp=e000027082200e40
<4> [<a00000010000a320>] ia64_leave_kernel+0x0/0x270
<4> sp=e000027082207bc0 bsp=e000027082200e40
<4> [<a000000100012cd0>] default_idle+0x110/0x180
<4> sp=e000027082207d90 bsp=e000027082200e00
<4> [<a0000001000127e0>] cpu_idle+0x1e0/0x300
<4> sp=e000027082207e30 bsp=e000027082200db8
<4> [<a0000001009fc4a0>] start_secondary+0x80/0xa0
<4> sp=e000027082207e30 bsp=e000027082200da0
<4> [<a00000010079d060>] __kprobes_text_end+0x340/0x370
<4> sp=e000027082207e30 bsp=e000027082200da0
Mike
>
> Thanks
> Boaz
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-18 19:51 ` Michael Reed
@ 2008-03-19 9:49 ` Boaz Harrosh
0 siblings, 0 replies; 18+ messages in thread
From: Boaz Harrosh @ 2008-03-19 9:49 UTC (permalink / raw)
To: Michael Reed; +Cc: linux-scsi
On Tue, Mar 18 2008 at 21:51 +0200, Michael Reed <mdr@sgi.com> wrote:
>
> Boaz Harrosh wrote:
>> On Tue, Mar 18 2008 at 19:13 +0200, Michael Reed <mdr@sgi.com> wrote:
>>> Boaz Harrosh wrote:
>>>> On Tue, Mar 18 2008 at 18:12 +0200, Michael Reed <mdr@sgi.com> wrote:
>>>>> Michael Reed wrote:
>>>>>> Boaz Harrosh wrote:
>>>>>> <snip>
>>>>>>>>> Just to demonstrate what I mean a patch is attached. Just as an RFC, totally
>>>>>>>>> untested.
>>>>>>>> I can try this out and see what happens.
>>>>>>>>
>>>>>>>>
>>>>>>> Will not compile here is a cleaner one
>>>>>> Still in my queue. Hopefully I'll get to poke at this today.
>>>>> Patch compiles cleanly and appears to have no effect on the misc.
>>>>> sg_* commands I've executed including sg_dd, sg_inq, sg_luns, sg_readcap.
>>>>>
>>>>> Mike
>>>>>
>>>>>> Mike
>>>>>>
>>>> <patch snipped>
>>>>
>>>> If you remove the original fix to sg.c
>>>> ([PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24)
>>>>
>>>> and apply this patch, does it solve your original infinite loop?
>>> By removing a fix in scsi_req_map_sg and forcing sg_start_req() to always
>>> call sg_build_indirect() (and not applying my fix to sg.c) I'm able to
>>> reproduce the problem without crashing the system.
>>>
>>> With your patch applied to 2.6.25-rc4-git3 I get this.... (The mptscsih_qcmd
>>> output is evidence that the condition was generated which would have caused
>>> the infinite loop.)
>>>
>>>
>
> < snip backtrace >
>
>>> Mike
>>>
>> I don't understand is that a NULL dereference due to my patch? did you manage to find
>> what is the line of code that dereferences the NULL pointer.
>
> I'm going to say "yes", it's due to your patch. It's happened twice in
> a row.
>
> Disabling inline functions gets me a better backtrace. And dumping
> the dmesg buffer I see the BUG in scsi_end_blk_request().
>
> BUG_ON(blk_end_bidi_request(req, 0, dlen, next_dlen));
>
OK Thanks that makes more sense. We hit the BUG_ON().
> I guess this is what I would expect to happen.
>
> blk_end_bidi_request ->
> blk_end_io ->
> __end_that_request_first
>
> __end_that_request_first returns "1" indicating that the
> request wasn't completely finished.
>
> I guess it could be argued that this really is a bug and that the
> buffer length and bi_size should always be the same. Would
> the same thing happen if a command returned a residual or
> an i/o error?
>
scsi's bufflen might not match bi_size. But in my patch I complete
according to request->data_len which should match bi_size. I guess that
is the bug in sg.c. However if you look in the patch I sent you for 2.6.24
I did a WARN_ON and then proceeded to complete the request in a loop. I
guess this is a more robust approach. If you could test with 2.6.24 + my
patch we could make sure it works. Expected behavior is that you'll get
lots of WARN_ON prints in dmsg but the IO should complete.
<snip back trace>
>
> Mike
>
Thanks Mike for all the testing. I feel guilty of you doing my job.
Boaz
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-18 17:19 ` Boaz Harrosh
@ 2008-03-19 15:57 ` Michael Reed
2008-03-19 16:18 ` Boaz Harrosh
0 siblings, 1 reply; 18+ messages in thread
From: Michael Reed @ 2008-03-19 15:57 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: linux-scsi
New patch at end....
Boaz Harrosh wrote:
> On Tue, Mar 18 2008 at 18:52 +0200, Michael Reed <mdr@sgi.com> wrote:
>> Boaz Harrosh wrote:
>>> On Tue, Mar 18 2008 at 18:12 +0200, Michael Reed <mdr@sgi.com> wrote:
>>>> Michael Reed wrote:
>>>>> Boaz Harrosh wrote:
>>>>> <snip>
>>>>>>>> Just to demonstrate what I mean a patch is attached. Just as an RFC, totally
>>>>>>>> untested.
>>>>>>> I can try this out and see what happens.
>>>>>>>
>>>>>>>
>>>>>> Will not compile here is a cleaner one
>>>>> Still in my queue. Hopefully I'll get to poke at this today.
>>>> Patch compiles cleanly and appears to have no effect on the misc.
>>>> sg_* commands I've executed including sg_dd, sg_inq, sg_luns, sg_readcap.
>>>>
>>>> Mike
>>>>
>>>>> Mike
>>>>>
>>> <patch sniped>
>>>
>>> If you remove the original fix to sg.c
>>> ([PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24)
>>>
>>> and apply this patch, does it solve your original infinite loop?
>> Unfortunately, the infinite loop only occurred at 2.6.24. I'll see if
>> I can break the current rc by removing some known fixes.
>>
>> Care to gen a patch for 2.6.24?
>>
>> Mike
>>
>>> Thanks
>>> Boaz
>>>
>
> here is the same principle on Linux 2.6.24
> ---
> [PATCH] scsi: Always complete BLOCK_PC commands
>
> Current code, in some IO combinations could wrongly retry
> a BLOCK_PC command in chunks. This was never intended.
> Fix it that BLOCK_PC will always complete atomically
>
> Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
> ---
> git-diff --stat -p
> drivers/scsi/scsi_lib.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index a9ac5b1..ae32012 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -966,7 +966,16 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
> req->sense_len = len;
> }
> }
> + good_bytes = req->data_len;
> req->data_len = cmd->resid;
> +retry_end_req:
> + if (scsi_end_request(cmd, 1, good_bytes, 0) != NULL) {
> + WARN_ON(1);
> + good_bytes = req->data_len;
> + goto retry_end_req;
> + }
> +
> + return;
> }
>
> /*
I applied the patch to 2.6.24 and here's the result. It first completes 255 bytes,
then repeatedly completes 56 bytes until it's all completed. This seems rather cumbersome.
And points out that the rounding in sg_build_indirect() needs to be fixed.
scsi_execute_async: inquiry buf length 255, use_sg 1, bio e0000170820fae00, bi_size 512
mptscsih_qcmd: cmd e0000170b06e1980 / 18, dd 2, sg_count 1, sglist e0000170b340e900, bufflen 255, bi_size 512
scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 255, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
WARNING: at drivers/scsi/scsi_lib.c:1025 scsi_io_completion()
Call Trace:
[<a000000100013ac0>] show_stack+0x40/0xa0
sp=e0000170821c79b0 bsp=e0000170821c1050
[<a000000100013b50>] dump_stack+0x30/0x60
sp=e0000170821c7b80 bsp=e0000170821c1038
[<a0000001005628b0>] scsi_io_completion+0x350/0x980
sp=e0000170821c7b80 bsp=e0000170821c0fd0
[<a0000001005547b0>] scsi_finish_command+0x1d0/0x200
sp=e0000170821c7ba0 bsp=e0000170821c0fa0
[<a000000100564070>] scsi_softirq_done+0x270/0x2a0
sp=e0000170821c7ba0 bsp=e0000170821c0f70
[<a0000001003a8480>] blk_done_softirq+0x140/0x1a0
sp=e0000170821c7bb0 bsp=e0000170821c0f58
[<a0000001000b6eb0>] __do_softirq+0xf0/0x240
sp=e0000170821c7bc0 bsp=e0000170821c0ee0
[<a0000001000b7070>] do_softirq+0x70/0xc0
sp=e0000170821c7bc0 bsp=e0000170821c0e80
[<a0000001000b7360>] irq_exit+0x80/0xa0
sp=e0000170821c7bc0 bsp=e0000170821c0e68
[<a000000100011250>] ia64_handle_irq+0x2f0/0x320
sp=e0000170821c7bc0 bsp=e0000170821c0e38
[<a00000010000b100>] ia64_leave_kernel+0x0/0x270
sp=e0000170821c7bc0 bsp=e0000170821c0e38
[<a000000100014bf0>] default_idle+0x110/0x180
sp=e0000170821c7d90 bsp=e0000170821c0df0
[<a000000100013870>] cpu_idle+0x230/0x360
sp=e0000170821c7e30 bsp=e0000170821c0db0
[<a000000100961910>] start_secondary+0x4d0/0x500
sp=e0000170821c7e30 bsp=e0000170821c0d70
[<a0000001007619c0>] __kprobes_text_end+0x340/0x370
sp=e0000170821c7e30 bsp=e0000170821c0d70
scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 56, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
WARNING: at drivers/scsi/scsi_lib.c:1025 scsi_io_completion()
Call Trace:
[<a000000100013ac0>] show_stack+0x40/0xa0
sp=e0000170821c79b0 bsp=e0000170821c1050
[<a000000100013b50>] dump_stack+0x30/0x60
sp=e0000170821c7b80 bsp=e0000170821c1038
[<a0000001005628b0>] scsi_io_completion+0x350/0x980
sp=e0000170821c7b80 bsp=e0000170821c0fd0
[<a0000001005547b0>] scsi_finish_command+0x1d0/0x200
sp=e0000170821c7ba0 bsp=e0000170821c0fa0
[<a000000100564070>] scsi_softirq_done+0x270/0x2a0
sp=e0000170821c7ba0 bsp=e0000170821c0f70
[<a0000001003a8480>] blk_done_softirq+0x140/0x1a0
sp=e0000170821c7bb0 bsp=e0000170821c0f58
[<a0000001000b6eb0>] __do_softirq+0xf0/0x240
sp=e0000170821c7bc0 bsp=e0000170821c0ee0
[<a0000001000b7070>] do_softirq+0x70/0xc0
sp=e0000170821c7bc0 bsp=e0000170821c0e80
[<a0000001000b7360>] irq_exit+0x80/0xa0
sp=e0000170821c7bc0 bsp=e0000170821c0e68
[<a000000100011250>] ia64_handle_irq+0x2f0/0x320
sp=e0000170821c7bc0 bsp=e0000170821c0e38
[<a00000010000b100>] ia64_leave_kernel+0x0/0x270
sp=e0000170821c7bc0 bsp=e0000170821c0e38
[<a000000100014bf0>] default_idle+0x110/0x180
sp=e0000170821c7d90 bsp=e0000170821c0df0
[<a000000100013870>] cpu_idle+0x230/0x360
sp=e0000170821c7e30 bsp=e0000170821c0db0
[<a000000100961910>] start_secondary+0x4d0/0x500
sp=e0000170821c7e30 bsp=e0000170821c0d70
[<a0000001007619c0>] __kprobes_text_end+0x340/0x370
sp=e0000170821c7e30 bsp=e0000170821c0d70
scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 56, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
WARNING: at drivers/scsi/scsi_lib.c:1025 scsi_io_completion()
Call Trace:
[<a000000100013ac0>] show_stack+0x40/0xa0
sp=e0000170821c79b0 bsp=e0000170821c1050
[<a000000100013b50>] dump_stack+0x30/0x60
sp=e0000170821c7b80 bsp=e0000170821c1038
[<a0000001005628b0>] scsi_io_completion+0x350/0x980
sp=e0000170821c7b80 bsp=e0000170821c0fd0
[<a0000001005547b0>] scsi_finish_command+0x1d0/0x200
sp=e0000170821c7ba0 bsp=e0000170821c0fa0
[<a000000100564070>] scsi_softirq_done+0x270/0x2a0
sp=e0000170821c7ba0 bsp=e0000170821c0f70
[<a0000001003a8480>] blk_done_softirq+0x140/0x1a0
sp=e0000170821c7bb0 bsp=e0000170821c0f58
[<a0000001000b6eb0>] __do_softirq+0xf0/0x240
sp=e0000170821c7bc0 bsp=e0000170821c0ee0
[<a0000001000b7070>] do_softirq+0x70/0xc0
sp=e0000170821c7bc0 bsp=e0000170821c0e80
[<a0000001000b7360>] irq_exit+0x80/0xa0
sp=e0000170821c7bc0 bsp=e0000170821c0e68
[<a000000100011250>] ia64_handle_irq+0x2f0/0x320
sp=e0000170821c7bc0 bsp=e0000170821c0e38
[<a00000010000b100>] ia64_leave_kernel+0x0/0x270
sp=e0000170821c7bc0 bsp=e0000170821c0e38
[<a000000100014bf0>] default_idle+0x110/0x180
sp=e0000170821c7d90 bsp=e0000170821c0df0
[<a000000100013870>] cpu_idle+0x230/0x360
sp=e0000170821c7e30 bsp=e0000170821c0db0
[<a000000100961910>] start_secondary+0x4d0/0x500
sp=e0000170821c7e30 bsp=e0000170821c0d70
[<a0000001007619c0>] __kprobes_text_end+0x340/0x370
sp=e0000170821c7e30 bsp=e0000170821c0d70
scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 56, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
WARNING: at drivers/scsi/scsi_lib.c:1025 scsi_io_completion()
Call Trace:
[<a000000100013ac0>] show_stack+0x40/0xa0
sp=e0000170821c79b0 bsp=e0000170821c1050
[<a000000100013b50>] dump_stack+0x30/0x60
sp=e0000170821c7b80 bsp=e0000170821c1038
[<a0000001005628b0>] scsi_io_completion+0x350/0x980
sp=e0000170821c7b80 bsp=e0000170821c0fd0
[<a0000001005547b0>] scsi_finish_command+0x1d0/0x200
sp=e0000170821c7ba0 bsp=e0000170821c0fa0
[<a000000100564070>] scsi_softirq_done+0x270/0x2a0
sp=e0000170821c7ba0 bsp=e0000170821c0f70
[<a0000001003a8480>] blk_done_softirq+0x140/0x1a0
sp=e0000170821c7bb0 bsp=e0000170821c0f58
[<a0000001000b6eb0>] __do_softirq+0xf0/0x240
sp=e0000170821c7bc0 bsp=e0000170821c0ee0
[<a0000001000b7070>] do_softirq+0x70/0xc0
sp=e0000170821c7bc0 bsp=e0000170821c0e80
[<a0000001000b7360>] irq_exit+0x80/0xa0
sp=e0000170821c7bc0 bsp=e0000170821c0e68
[<a000000100011250>] ia64_handle_irq+0x2f0/0x320
sp=e0000170821c7bc0 bsp=e0000170821c0e38
[<a00000010000b100>] ia64_leave_kernel+0x0/0x270
sp=e0000170821c7bc0 bsp=e0000170821c0e38
[<a000000100014bf0>] default_idle+0x110/0x180
sp=e0000170821c7d90 bsp=e0000170821c0df0
[<a000000100013870>] cpu_idle+0x230/0x360
sp=e0000170821c7e30 bsp=e0000170821c0db0
[<a000000100961910>] start_secondary+0x4d0/0x500
sp=e0000170821c7e30 bsp=e0000170821c0d70
[<a0000001007619c0>] __kprobes_text_end+0x340/0x370
sp=e0000170821c7e30 bsp=e0000170821c0d70
scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 56, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
WARNING: at drivers/scsi/scsi_lib.c:1025 scsi_io_completion()
Call Trace:
[<a000000100013ac0>] show_stack+0x40/0xa0
sp=e0000170821c79b0 bsp=e0000170821c1050
[<a000000100013b50>] dump_stack+0x30/0x60
sp=e0000170821c7b80 bsp=e0000170821c1038
[<a0000001005628b0>] scsi_io_completion+0x350/0x980
sp=e0000170821c7b80 bsp=e0000170821c0fd0
[<a0000001005547b0>] scsi_finish_command+0x1d0/0x200
sp=e0000170821c7ba0 bsp=e0000170821c0fa0
[<a000000100564070>] scsi_softirq_done+0x270/0x2a0
sp=e0000170821c7ba0 bsp=e0000170821c0f70
[<a0000001003a8480>] blk_done_softirq+0x140/0x1a0
sp=e0000170821c7bb0 bsp=e0000170821c0f58
[<a0000001000b6eb0>] __do_softirq+0xf0/0x240
sp=e0000170821c7bc0 bsp=e0000170821c0ee0
[<a0000001000b7070>] do_softirq+0x70/0xc0
sp=e0000170821c7bc0 bsp=e0000170821c0e80
[<a0000001000b7360>] irq_exit+0x80/0xa0
sp=e0000170821c7bc0 bsp=e0000170821c0e68
[<a000000100011250>] ia64_handle_irq+0x2f0/0x320
sp=e0000170821c7bc0 bsp=e0000170821c0e38
[<a00000010000b100>] ia64_leave_kernel+0x0/0x270
sp=e0000170821c7bc0 bsp=e0000170821c0e38
[<a000000100014bf0>] default_idle+0x110/0x180
sp=e0000170821c7d90 bsp=e0000170821c0df0
[<a000000100013870>] cpu_idle+0x230/0x360
sp=e0000170821c7e30 bsp=e0000170821c0db0
[<a000000100961910>] start_secondary+0x4d0/0x500
sp=e0000170821c7e30 bsp=e0000170821c0d70
[<a0000001007619c0>] __kprobes_text_end+0x340/0x370
sp=e0000170821c7e30 bsp=e0000170821c0d70
scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 56, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
How 'bout this instead? It completes what finished and then
ends the request. I think. I tried it using 2.6.24 and got
no infinite loop.
--- kdbu/drivers/scsi/scsi_lib.c 2008-01-24 14:58:37.000000000 -0800
+++ kdb/drivers/scsi/scsi_lib.c 2008-03-19 08:49:19.456568385 -0700
@@ -657,13 +657,12 @@ static struct scsi_cmnd *scsi_end_reques
/*
* If there are blocks left over at the end, set up the command
* to queue the remainder of them.
+ * blk_pc_requests are never requeued.
*/
- if (end_that_request_chunk(req, uptodate, bytes)) {
+ if (end_that_request_chunk(req, uptodate, bytes) &&
+ !blk_pc_request(req)) {
int leftover = (req->hard_nr_sectors << 9);
- if (blk_pc_request(req))
- leftover = req->data_len;
-
/* kill remainder if no retrys */
if (!uptodate && blk_noretry_request(req))
end_that_request_chunk(req, 0, leftover);
Signed-off-by: Michael Reed <mdr@sgi.com>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-19 15:57 ` Michael Reed
@ 2008-03-19 16:18 ` Boaz Harrosh
2008-03-19 21:34 ` Michael Reed
0 siblings, 1 reply; 18+ messages in thread
From: Boaz Harrosh @ 2008-03-19 16:18 UTC (permalink / raw)
To: Michael Reed; +Cc: linux-scsi
On Wed, Mar 19 2008 at 17:57 +0200, Michael Reed <mdr@sgi.com> wrote:
> New patch at end....
>
> Boaz Harrosh wrote:
>> On Tue, Mar 18 2008 at 18:52 +0200, Michael Reed <mdr@sgi.com> wrote:
>>> Boaz Harrosh wrote:
>>>> On Tue, Mar 18 2008 at 18:12 +0200, Michael Reed <mdr@sgi.com> wrote:
>>>>> Michael Reed wrote:
>>>>>> Boaz Harrosh wrote:
>>>>>> <snip>
>>>>>>>>> Just to demonstrate what I mean a patch is attached. Just as an RFC, totally
>>>>>>>>> untested.
>>>>>>>> I can try this out and see what happens.
>>>>>>>>
>>>>>>>>
>>>>>>> Will not compile here is a cleaner one
>>>>>> Still in my queue. Hopefully I'll get to poke at this today.
>>>>> Patch compiles cleanly and appears to have no effect on the misc.
>>>>> sg_* commands I've executed including sg_dd, sg_inq, sg_luns, sg_readcap.
>>>>>
>>>>> Mike
>>>>>
>>>>>> Mike
>>>>>>
>>>> <patch sniped>
>>>>
>>>> If you remove the original fix to sg.c
>>>> ([PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24)
>>>>
>>>> and apply this patch, does it solve your original infinite loop?
>>> Unfortunately, the infinite loop only occurred at 2.6.24. I'll see if
>>> I can break the current rc by removing some known fixes.
>>>
>>> Care to gen a patch for 2.6.24?
>>>
>>> Mike
>>>
>>>> Thanks
>>>> Boaz
>>>>
>> here is the same principle on Linux 2.6.24
>> ---
>> [PATCH] scsi: Always complete BLOCK_PC commands
>>
>> Current code, in some IO combinations could wrongly retry
>> a BLOCK_PC command in chunks. This was never intended.
>> Fix it that BLOCK_PC will always complete atomically
>>
>> Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
>> ---
>> git-diff --stat -p
>> drivers/scsi/scsi_lib.c | 9 +++++++++
>> 1 files changed, 9 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index a9ac5b1..ae32012 100644
>> --- a/drivers/scsi/scsi_lib.c
>> +++ b/drivers/scsi/scsi_lib.c
>> @@ -966,7 +966,16 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
>> req->sense_len = len;
>> }
>> }
>> + good_bytes = req->data_len;
>> req->data_len = cmd->resid;
>> +retry_end_req:
>> + if (scsi_end_request(cmd, 1, good_bytes, 0) != NULL) {
>> + WARN_ON(1);
>> + good_bytes = req->data_len;
>> + goto retry_end_req;
>> + }
>> +
>> + return;
>> }
>>
>> /*
>
> I applied the patch to 2.6.24 and here's the result. It first completes 255 bytes,
> then repeatedly completes 56 bytes until it's all completed. This seems rather cumbersome.
> And points out that the rounding in sg_build_indirect() needs to be fixed.
>
> scsi_execute_async: inquiry buf length 255, use_sg 1, bio e0000170820fae00, bi_size 512
> mptscsih_qcmd: cmd e0000170b06e1980 / 18, dd 2, sg_count 1, sglist e0000170b340e900, bufflen 255, bi_size 512
> scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 255, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
> WARNING: at drivers/scsi/scsi_lib.c:1025 scsi_io_completion()
>
> Call Trace:
> [<a000000100013ac0>] show_stack+0x40/0xa0
> sp=e0000170821c79b0 bsp=e0000170821c1050
> [<a000000100013b50>] dump_stack+0x30/0x60
> sp=e0000170821c7b80 bsp=e0000170821c1038
> [<a0000001005628b0>] scsi_io_completion+0x350/0x980
> sp=e0000170821c7b80 bsp=e0000170821c0fd0
> [<a0000001005547b0>] scsi_finish_command+0x1d0/0x200
> sp=e0000170821c7ba0 bsp=e0000170821c0fa0
> [<a000000100564070>] scsi_softirq_done+0x270/0x2a0
> sp=e0000170821c7ba0 bsp=e0000170821c0f70
> [<a0000001003a8480>] blk_done_softirq+0x140/0x1a0
> sp=e0000170821c7bb0 bsp=e0000170821c0f58
> [<a0000001000b6eb0>] __do_softirq+0xf0/0x240
> sp=e0000170821c7bc0 bsp=e0000170821c0ee0
> [<a0000001000b7070>] do_softirq+0x70/0xc0
> sp=e0000170821c7bc0 bsp=e0000170821c0e80
> [<a0000001000b7360>] irq_exit+0x80/0xa0
> sp=e0000170821c7bc0 bsp=e0000170821c0e68
> [<a000000100011250>] ia64_handle_irq+0x2f0/0x320
> sp=e0000170821c7bc0 bsp=e0000170821c0e38
> [<a00000010000b100>] ia64_leave_kernel+0x0/0x270
> sp=e0000170821c7bc0 bsp=e0000170821c0e38
> [<a000000100014bf0>] default_idle+0x110/0x180
> sp=e0000170821c7d90 bsp=e0000170821c0df0
> [<a000000100013870>] cpu_idle+0x230/0x360
> sp=e0000170821c7e30 bsp=e0000170821c0db0
> [<a000000100961910>] start_secondary+0x4d0/0x500
> sp=e0000170821c7e30 bsp=e0000170821c0d70
> [<a0000001007619c0>] __kprobes_text_end+0x340/0x370
> sp=e0000170821c7e30 bsp=e0000170821c0d70
> scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 56, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
> WARNING: at drivers/scsi/scsi_lib.c:1025 scsi_io_completion()
>
> Call Trace:
> [<a000000100013ac0>] show_stack+0x40/0xa0
> sp=e0000170821c79b0 bsp=e0000170821c1050
> [<a000000100013b50>] dump_stack+0x30/0x60
> sp=e0000170821c7b80 bsp=e0000170821c1038
> [<a0000001005628b0>] scsi_io_completion+0x350/0x980
> sp=e0000170821c7b80 bsp=e0000170821c0fd0
> [<a0000001005547b0>] scsi_finish_command+0x1d0/0x200
> sp=e0000170821c7ba0 bsp=e0000170821c0fa0
> [<a000000100564070>] scsi_softirq_done+0x270/0x2a0
> sp=e0000170821c7ba0 bsp=e0000170821c0f70
> [<a0000001003a8480>] blk_done_softirq+0x140/0x1a0
> sp=e0000170821c7bb0 bsp=e0000170821c0f58
> [<a0000001000b6eb0>] __do_softirq+0xf0/0x240
> sp=e0000170821c7bc0 bsp=e0000170821c0ee0
> [<a0000001000b7070>] do_softirq+0x70/0xc0
> sp=e0000170821c7bc0 bsp=e0000170821c0e80
> [<a0000001000b7360>] irq_exit+0x80/0xa0
> sp=e0000170821c7bc0 bsp=e0000170821c0e68
> [<a000000100011250>] ia64_handle_irq+0x2f0/0x320
> sp=e0000170821c7bc0 bsp=e0000170821c0e38
> [<a00000010000b100>] ia64_leave_kernel+0x0/0x270
> sp=e0000170821c7bc0 bsp=e0000170821c0e38
> [<a000000100014bf0>] default_idle+0x110/0x180
> sp=e0000170821c7d90 bsp=e0000170821c0df0
> [<a000000100013870>] cpu_idle+0x230/0x360
> sp=e0000170821c7e30 bsp=e0000170821c0db0
> [<a000000100961910>] start_secondary+0x4d0/0x500
> sp=e0000170821c7e30 bsp=e0000170821c0d70
> [<a0000001007619c0>] __kprobes_text_end+0x340/0x370
> sp=e0000170821c7e30 bsp=e0000170821c0d70
> scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 56, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
> WARNING: at drivers/scsi/scsi_lib.c:1025 scsi_io_completion()
>
> Call Trace:
> [<a000000100013ac0>] show_stack+0x40/0xa0
> sp=e0000170821c79b0 bsp=e0000170821c1050
> [<a000000100013b50>] dump_stack+0x30/0x60
> sp=e0000170821c7b80 bsp=e0000170821c1038
> [<a0000001005628b0>] scsi_io_completion+0x350/0x980
> sp=e0000170821c7b80 bsp=e0000170821c0fd0
> [<a0000001005547b0>] scsi_finish_command+0x1d0/0x200
> sp=e0000170821c7ba0 bsp=e0000170821c0fa0
> [<a000000100564070>] scsi_softirq_done+0x270/0x2a0
> sp=e0000170821c7ba0 bsp=e0000170821c0f70
> [<a0000001003a8480>] blk_done_softirq+0x140/0x1a0
> sp=e0000170821c7bb0 bsp=e0000170821c0f58
> [<a0000001000b6eb0>] __do_softirq+0xf0/0x240
> sp=e0000170821c7bc0 bsp=e0000170821c0ee0
> [<a0000001000b7070>] do_softirq+0x70/0xc0
> sp=e0000170821c7bc0 bsp=e0000170821c0e80
> [<a0000001000b7360>] irq_exit+0x80/0xa0
> sp=e0000170821c7bc0 bsp=e0000170821c0e68
> [<a000000100011250>] ia64_handle_irq+0x2f0/0x320
> sp=e0000170821c7bc0 bsp=e0000170821c0e38
> [<a00000010000b100>] ia64_leave_kernel+0x0/0x270
> sp=e0000170821c7bc0 bsp=e0000170821c0e38
> [<a000000100014bf0>] default_idle+0x110/0x180
> sp=e0000170821c7d90 bsp=e0000170821c0df0
> [<a000000100013870>] cpu_idle+0x230/0x360
> sp=e0000170821c7e30 bsp=e0000170821c0db0
> [<a000000100961910>] start_secondary+0x4d0/0x500
> sp=e0000170821c7e30 bsp=e0000170821c0d70
> [<a0000001007619c0>] __kprobes_text_end+0x340/0x370
> sp=e0000170821c7e30 bsp=e0000170821c0d70
> scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 56, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
> WARNING: at drivers/scsi/scsi_lib.c:1025 scsi_io_completion()
>
> Call Trace:
> [<a000000100013ac0>] show_stack+0x40/0xa0
> sp=e0000170821c79b0 bsp=e0000170821c1050
> [<a000000100013b50>] dump_stack+0x30/0x60
> sp=e0000170821c7b80 bsp=e0000170821c1038
> [<a0000001005628b0>] scsi_io_completion+0x350/0x980
> sp=e0000170821c7b80 bsp=e0000170821c0fd0
> [<a0000001005547b0>] scsi_finish_command+0x1d0/0x200
> sp=e0000170821c7ba0 bsp=e0000170821c0fa0
> [<a000000100564070>] scsi_softirq_done+0x270/0x2a0
> sp=e0000170821c7ba0 bsp=e0000170821c0f70
> [<a0000001003a8480>] blk_done_softirq+0x140/0x1a0
> sp=e0000170821c7bb0 bsp=e0000170821c0f58
> [<a0000001000b6eb0>] __do_softirq+0xf0/0x240
> sp=e0000170821c7bc0 bsp=e0000170821c0ee0
> [<a0000001000b7070>] do_softirq+0x70/0xc0
> sp=e0000170821c7bc0 bsp=e0000170821c0e80
> [<a0000001000b7360>] irq_exit+0x80/0xa0
> sp=e0000170821c7bc0 bsp=e0000170821c0e68
> [<a000000100011250>] ia64_handle_irq+0x2f0/0x320
> sp=e0000170821c7bc0 bsp=e0000170821c0e38
> [<a00000010000b100>] ia64_leave_kernel+0x0/0x270
> sp=e0000170821c7bc0 bsp=e0000170821c0e38
> [<a000000100014bf0>] default_idle+0x110/0x180
> sp=e0000170821c7d90 bsp=e0000170821c0df0
> [<a000000100013870>] cpu_idle+0x230/0x360
> sp=e0000170821c7e30 bsp=e0000170821c0db0
> [<a000000100961910>] start_secondary+0x4d0/0x500
> sp=e0000170821c7e30 bsp=e0000170821c0d70
> [<a0000001007619c0>] __kprobes_text_end+0x340/0x370
> sp=e0000170821c7e30 bsp=e0000170821c0d70
> scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 56, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
> WARNING: at drivers/scsi/scsi_lib.c:1025 scsi_io_completion()
>
> Call Trace:
> [<a000000100013ac0>] show_stack+0x40/0xa0
> sp=e0000170821c79b0 bsp=e0000170821c1050
> [<a000000100013b50>] dump_stack+0x30/0x60
> sp=e0000170821c7b80 bsp=e0000170821c1038
> [<a0000001005628b0>] scsi_io_completion+0x350/0x980
> sp=e0000170821c7b80 bsp=e0000170821c0fd0
> [<a0000001005547b0>] scsi_finish_command+0x1d0/0x200
> sp=e0000170821c7ba0 bsp=e0000170821c0fa0
> [<a000000100564070>] scsi_softirq_done+0x270/0x2a0
> sp=e0000170821c7ba0 bsp=e0000170821c0f70
> [<a0000001003a8480>] blk_done_softirq+0x140/0x1a0
> sp=e0000170821c7bb0 bsp=e0000170821c0f58
> [<a0000001000b6eb0>] __do_softirq+0xf0/0x240
> sp=e0000170821c7bc0 bsp=e0000170821c0ee0
> [<a0000001000b7070>] do_softirq+0x70/0xc0
> sp=e0000170821c7bc0 bsp=e0000170821c0e80
> [<a0000001000b7360>] irq_exit+0x80/0xa0
> sp=e0000170821c7bc0 bsp=e0000170821c0e68
> [<a000000100011250>] ia64_handle_irq+0x2f0/0x320
> sp=e0000170821c7bc0 bsp=e0000170821c0e38
> [<a00000010000b100>] ia64_leave_kernel+0x0/0x270
> sp=e0000170821c7bc0 bsp=e0000170821c0e38
> [<a000000100014bf0>] default_idle+0x110/0x180
> sp=e0000170821c7d90 bsp=e0000170821c0df0
> [<a000000100013870>] cpu_idle+0x230/0x360
> sp=e0000170821c7e30 bsp=e0000170821c0db0
> [<a000000100961910>] start_secondary+0x4d0/0x500
> sp=e0000170821c7e30 bsp=e0000170821c0d70
> [<a0000001007619c0>] __kprobes_text_end+0x340/0x370
> sp=e0000170821c7e30 bsp=e0000170821c0d70
> scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 56, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
>
>
> How 'bout this instead? It completes what finished and then
> ends the request. I think. I tried it using 2.6.24 and got
> no infinite loop.
>
>
>
> --- kdbu/drivers/scsi/scsi_lib.c 2008-01-24 14:58:37.000000000 -0800
> +++ kdb/drivers/scsi/scsi_lib.c 2008-03-19 08:49:19.456568385 -0700
> @@ -657,13 +657,12 @@ static struct scsi_cmnd *scsi_end_reques
> /*
> * If there are blocks left over at the end, set up the command
> * to queue the remainder of them.
> + * blk_pc_requests are never requeued.
> */
> - if (end_that_request_chunk(req, uptodate, bytes)) {
> + if (end_that_request_chunk(req, uptodate, bytes) &&
> + !blk_pc_request(req)) {
> int leftover = (req->hard_nr_sectors << 9);
>
> - if (blk_pc_request(req))
> - leftover = req->data_len;
> -
> /* kill remainder if no retrys */
> if (!uptodate && blk_noretry_request(req))
> end_that_request_chunk(req, 0, leftover);
>
> Signed-off-by: Michael Reed <mdr@sgi.com>
This will not work. Failing to complete the remaining of the request like that
will leak BIOs. The upper layer bugs must be fixed. The WARN_ON is good because
it identifies a bug at upper layer that must be fixed but goes on to
complete the request. What you could do that will work well is at:
+ WARN_ON(1);
+ good_bytes = req->data_len;
+ goto retry_end_req;
change that to be:
+ WARN_ON(1);
+ good_bytes = ~0;
+ goto retry_end_req;
This will always insure a full complete of the request the second round, but
will keep the WARN_ON for one time. The patch to scsi_req_map_sg should be applied
for the stable 2.6.24.x releases, it is a bug.
Boaz
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24
2008-03-19 16:18 ` Boaz Harrosh
@ 2008-03-19 21:34 ` Michael Reed
0 siblings, 0 replies; 18+ messages in thread
From: Michael Reed @ 2008-03-19 21:34 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: linux-scsi
Boaz Harrosh wrote:
> On Wed, Mar 19 2008 at 17:57 +0200, Michael Reed <mdr@sgi.com> wrote:
>> New patch at end....
>>
>> Boaz Harrosh wrote:
>>> On Tue, Mar 18 2008 at 18:52 +0200, Michael Reed <mdr@sgi.com> wrote:
>>>> Boaz Harrosh wrote:
>>>>> On Tue, Mar 18 2008 at 18:12 +0200, Michael Reed <mdr@sgi.com> wrote:
>>>>>> Michael Reed wrote:
>>>>>>> Boaz Harrosh wrote:
>>>>>>> <snip>
>>>>>>>>>> Just to demonstrate what I mean a patch is attached. Just as an RFC, totally
>>>>>>>>>> untested.
>>>>>>>>> I can try this out and see what happens.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Will not compile here is a cleaner one
>>>>>>> Still in my queue. Hopefully I'll get to poke at this today.
>>>>>> Patch compiles cleanly and appears to have no effect on the misc.
>>>>>> sg_* commands I've executed including sg_dd, sg_inq, sg_luns, sg_readcap.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>> <patch sniped>
>>>>>
>>>>> If you remove the original fix to sg.c
>>>>> ([PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24)
>>>>>
>>>>> and apply this patch, does it solve your original infinite loop?
>>>> Unfortunately, the infinite loop only occurred at 2.6.24. I'll see if
>>>> I can break the current rc by removing some known fixes.
>>>>
>>>> Care to gen a patch for 2.6.24?
>>>>
>>>> Mike
>>>>
>>>>> Thanks
>>>>> Boaz
>>>>>
>>> here is the same principle on Linux 2.6.24
>>> ---
>>> [PATCH] scsi: Always complete BLOCK_PC commands
>>>
>>> Current code, in some IO combinations could wrongly retry
>>> a BLOCK_PC command in chunks. This was never intended.
>>> Fix it that BLOCK_PC will always complete atomically
>>>
>>> Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
>>> ---
>>> git-diff --stat -p
>>> drivers/scsi/scsi_lib.c | 9 +++++++++
>>> 1 files changed, 9 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>>> index a9ac5b1..ae32012 100644
>>> --- a/drivers/scsi/scsi_lib.c
>>> +++ b/drivers/scsi/scsi_lib.c
>>> @@ -966,7 +966,16 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
>>> req->sense_len = len;
>>> }
>>> }
>>> + good_bytes = req->data_len;
>>> req->data_len = cmd->resid;
>>> +retry_end_req:
>>> + if (scsi_end_request(cmd, 1, good_bytes, 0) != NULL) {
>>> + WARN_ON(1);
>>> + good_bytes = req->data_len;
>>> + goto retry_end_req;
>>> + }
>>> +
>>> + return;
>>> }
>>>
>>> /*
>> I applied the patch to 2.6.24 and here's the result. It first completes 255 bytes,
>> then repeatedly completes 56 bytes until it's all completed. This seems rather cumbersome.
>> And points out that the rounding in sg_build_indirect() needs to be fixed.
>>
>> scsi_execute_async: inquiry buf length 255, use_sg 1, bio e0000170820fae00, bi_size 512
>> mptscsih_qcmd: cmd e0000170b06e1980 / 18, dd 2, sg_count 1, sglist e0000170b340e900, bufflen 255, bi_size 512
>> scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 255, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
>> WARNING: at drivers/scsi/scsi_lib.c:1025 scsi_io_completion()
>>
>> Call Trace:
>> [<a000000100013ac0>] show_stack+0x40/0xa0
>> sp=e0000170821c79b0 bsp=e0000170821c1050
>> [<a000000100013b50>] dump_stack+0x30/0x60
>> sp=e0000170821c7b80 bsp=e0000170821c1038
>> [<a0000001005628b0>] scsi_io_completion+0x350/0x980
>> sp=e0000170821c7b80 bsp=e0000170821c0fd0
>> [<a0000001005547b0>] scsi_finish_command+0x1d0/0x200
>> sp=e0000170821c7ba0 bsp=e0000170821c0fa0
>> [<a000000100564070>] scsi_softirq_done+0x270/0x2a0
>> sp=e0000170821c7ba0 bsp=e0000170821c0f70
>> [<a0000001003a8480>] blk_done_softirq+0x140/0x1a0
>> sp=e0000170821c7bb0 bsp=e0000170821c0f58
>> [<a0000001000b6eb0>] __do_softirq+0xf0/0x240
>> sp=e0000170821c7bc0 bsp=e0000170821c0ee0
>> [<a0000001000b7070>] do_softirq+0x70/0xc0
>> sp=e0000170821c7bc0 bsp=e0000170821c0e80
>> [<a0000001000b7360>] irq_exit+0x80/0xa0
>> sp=e0000170821c7bc0 bsp=e0000170821c0e68
>> [<a000000100011250>] ia64_handle_irq+0x2f0/0x320
>> sp=e0000170821c7bc0 bsp=e0000170821c0e38
>> [<a00000010000b100>] ia64_leave_kernel+0x0/0x270
>> sp=e0000170821c7bc0 bsp=e0000170821c0e38
>> [<a000000100014bf0>] default_idle+0x110/0x180
>> sp=e0000170821c7d90 bsp=e0000170821c0df0
>> [<a000000100013870>] cpu_idle+0x230/0x360
>> sp=e0000170821c7e30 bsp=e0000170821c0db0
>> [<a000000100961910>] start_secondary+0x4d0/0x500
>> sp=e0000170821c7e30 bsp=e0000170821c0d70
>> [<a0000001007619c0>] __kprobes_text_end+0x340/0x370
>> sp=e0000170821c7e30 bsp=e0000170821c0d70
>> scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 56, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
>> WARNING: at drivers/scsi/scsi_lib.c:1025 scsi_io_completion()
>>
>> Call Trace:
>> [<a000000100013ac0>] show_stack+0x40/0xa0
>> sp=e0000170821c79b0 bsp=e0000170821c1050
>> [<a000000100013b50>] dump_stack+0x30/0x60
>> sp=e0000170821c7b80 bsp=e0000170821c1038
>> [<a0000001005628b0>] scsi_io_completion+0x350/0x980
>> sp=e0000170821c7b80 bsp=e0000170821c0fd0
>> [<a0000001005547b0>] scsi_finish_command+0x1d0/0x200
>> sp=e0000170821c7ba0 bsp=e0000170821c0fa0
>> [<a000000100564070>] scsi_softirq_done+0x270/0x2a0
>> sp=e0000170821c7ba0 bsp=e0000170821c0f70
>> [<a0000001003a8480>] blk_done_softirq+0x140/0x1a0
>> sp=e0000170821c7bb0 bsp=e0000170821c0f58
>> [<a0000001000b6eb0>] __do_softirq+0xf0/0x240
>> sp=e0000170821c7bc0 bsp=e0000170821c0ee0
>> [<a0000001000b7070>] do_softirq+0x70/0xc0
>> sp=e0000170821c7bc0 bsp=e0000170821c0e80
>> [<a0000001000b7360>] irq_exit+0x80/0xa0
>> sp=e0000170821c7bc0 bsp=e0000170821c0e68
>> [<a000000100011250>] ia64_handle_irq+0x2f0/0x320
>> sp=e0000170821c7bc0 bsp=e0000170821c0e38
>> [<a00000010000b100>] ia64_leave_kernel+0x0/0x270
>> sp=e0000170821c7bc0 bsp=e0000170821c0e38
>> [<a000000100014bf0>] default_idle+0x110/0x180
>> sp=e0000170821c7d90 bsp=e0000170821c0df0
>> [<a000000100013870>] cpu_idle+0x230/0x360
>> sp=e0000170821c7e30 bsp=e0000170821c0db0
>> [<a000000100961910>] start_secondary+0x4d0/0x500
>> sp=e0000170821c7e30 bsp=e0000170821c0d70
>> [<a0000001007619c0>] __kprobes_text_end+0x340/0x370
>> sp=e0000170821c7e30 bsp=e0000170821c0d70
>> scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 56, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
>> WARNING: at drivers/scsi/scsi_lib.c:1025 scsi_io_completion()
>>
>> Call Trace:
>> [<a000000100013ac0>] show_stack+0x40/0xa0
>> sp=e0000170821c79b0 bsp=e0000170821c1050
>> [<a000000100013b50>] dump_stack+0x30/0x60
>> sp=e0000170821c7b80 bsp=e0000170821c1038
>> [<a0000001005628b0>] scsi_io_completion+0x350/0x980
>> sp=e0000170821c7b80 bsp=e0000170821c0fd0
>> [<a0000001005547b0>] scsi_finish_command+0x1d0/0x200
>> sp=e0000170821c7ba0 bsp=e0000170821c0fa0
>> [<a000000100564070>] scsi_softirq_done+0x270/0x2a0
>> sp=e0000170821c7ba0 bsp=e0000170821c0f70
>> [<a0000001003a8480>] blk_done_softirq+0x140/0x1a0
>> sp=e0000170821c7bb0 bsp=e0000170821c0f58
>> [<a0000001000b6eb0>] __do_softirq+0xf0/0x240
>> sp=e0000170821c7bc0 bsp=e0000170821c0ee0
>> [<a0000001000b7070>] do_softirq+0x70/0xc0
>> sp=e0000170821c7bc0 bsp=e0000170821c0e80
>> [<a0000001000b7360>] irq_exit+0x80/0xa0
>> sp=e0000170821c7bc0 bsp=e0000170821c0e68
>> [<a000000100011250>] ia64_handle_irq+0x2f0/0x320
>> sp=e0000170821c7bc0 bsp=e0000170821c0e38
>> [<a00000010000b100>] ia64_leave_kernel+0x0/0x270
>> sp=e0000170821c7bc0 bsp=e0000170821c0e38
>> [<a000000100014bf0>] default_idle+0x110/0x180
>> sp=e0000170821c7d90 bsp=e0000170821c0df0
>> [<a000000100013870>] cpu_idle+0x230/0x360
>> sp=e0000170821c7e30 bsp=e0000170821c0db0
>> [<a000000100961910>] start_secondary+0x4d0/0x500
>> sp=e0000170821c7e30 bsp=e0000170821c0d70
>> [<a0000001007619c0>] __kprobes_text_end+0x340/0x370
>> sp=e0000170821c7e30 bsp=e0000170821c0d70
>> scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 56, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
>> WARNING: at drivers/scsi/scsi_lib.c:1025 scsi_io_completion()
>>
>> Call Trace:
>> [<a000000100013ac0>] show_stack+0x40/0xa0
>> sp=e0000170821c79b0 bsp=e0000170821c1050
>> [<a000000100013b50>] dump_stack+0x30/0x60
>> sp=e0000170821c7b80 bsp=e0000170821c1038
>> [<a0000001005628b0>] scsi_io_completion+0x350/0x980
>> sp=e0000170821c7b80 bsp=e0000170821c0fd0
>> [<a0000001005547b0>] scsi_finish_command+0x1d0/0x200
>> sp=e0000170821c7ba0 bsp=e0000170821c0fa0
>> [<a000000100564070>] scsi_softirq_done+0x270/0x2a0
>> sp=e0000170821c7ba0 bsp=e0000170821c0f70
>> [<a0000001003a8480>] blk_done_softirq+0x140/0x1a0
>> sp=e0000170821c7bb0 bsp=e0000170821c0f58
>> [<a0000001000b6eb0>] __do_softirq+0xf0/0x240
>> sp=e0000170821c7bc0 bsp=e0000170821c0ee0
>> [<a0000001000b7070>] do_softirq+0x70/0xc0
>> sp=e0000170821c7bc0 bsp=e0000170821c0e80
>> [<a0000001000b7360>] irq_exit+0x80/0xa0
>> sp=e0000170821c7bc0 bsp=e0000170821c0e68
>> [<a000000100011250>] ia64_handle_irq+0x2f0/0x320
>> sp=e0000170821c7bc0 bsp=e0000170821c0e38
>> [<a00000010000b100>] ia64_leave_kernel+0x0/0x270
>> sp=e0000170821c7bc0 bsp=e0000170821c0e38
>> [<a000000100014bf0>] default_idle+0x110/0x180
>> sp=e0000170821c7d90 bsp=e0000170821c0df0
>> [<a000000100013870>] cpu_idle+0x230/0x360
>> sp=e0000170821c7e30 bsp=e0000170821c0db0
>> [<a000000100961910>] start_secondary+0x4d0/0x500
>> sp=e0000170821c7e30 bsp=e0000170821c0d70
>> [<a0000001007619c0>] __kprobes_text_end+0x340/0x370
>> sp=e0000170821c7e30 bsp=e0000170821c0d70
>> scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 56, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
>> WARNING: at drivers/scsi/scsi_lib.c:1025 scsi_io_completion()
>>
>> Call Trace:
>> [<a000000100013ac0>] show_stack+0x40/0xa0
>> sp=e0000170821c79b0 bsp=e0000170821c1050
>> [<a000000100013b50>] dump_stack+0x30/0x60
>> sp=e0000170821c7b80 bsp=e0000170821c1038
>> [<a0000001005628b0>] scsi_io_completion+0x350/0x980
>> sp=e0000170821c7b80 bsp=e0000170821c0fd0
>> [<a0000001005547b0>] scsi_finish_command+0x1d0/0x200
>> sp=e0000170821c7ba0 bsp=e0000170821c0fa0
>> [<a000000100564070>] scsi_softirq_done+0x270/0x2a0
>> sp=e0000170821c7ba0 bsp=e0000170821c0f70
>> [<a0000001003a8480>] blk_done_softirq+0x140/0x1a0
>> sp=e0000170821c7bb0 bsp=e0000170821c0f58
>> [<a0000001000b6eb0>] __do_softirq+0xf0/0x240
>> sp=e0000170821c7bc0 bsp=e0000170821c0ee0
>> [<a0000001000b7070>] do_softirq+0x70/0xc0
>> sp=e0000170821c7bc0 bsp=e0000170821c0e80
>> [<a0000001000b7360>] irq_exit+0x80/0xa0
>> sp=e0000170821c7bc0 bsp=e0000170821c0e68
>> [<a000000100011250>] ia64_handle_irq+0x2f0/0x320
>> sp=e0000170821c7bc0 bsp=e0000170821c0e38
>> [<a00000010000b100>] ia64_leave_kernel+0x0/0x270
>> sp=e0000170821c7bc0 bsp=e0000170821c0e38
>> [<a000000100014bf0>] default_idle+0x110/0x180
>> sp=e0000170821c7d90 bsp=e0000170821c0df0
>> [<a000000100013870>] cpu_idle+0x230/0x360
>> sp=e0000170821c7e30 bsp=e0000170821c0db0
>> [<a000000100961910>] start_secondary+0x4d0/0x500
>> sp=e0000170821c7e30 bsp=e0000170821c0d70
>> [<a0000001007619c0>] __kprobes_text_end+0x340/0x370
>> sp=e0000170821c7e30 bsp=e0000170821c0d70
>> scsi_io_completion: e0000170b06e1980: inquiry completion: result 0, good_bytes 56, bufflen 255, sense_valid 0, sense e0000170b34ac5c0 / 0
>>
>>
>> How 'bout this instead? It completes what finished and then
>> ends the request. I think. I tried it using 2.6.24 and got
>> no infinite loop.
>>
>>
>>
>> --- kdbu/drivers/scsi/scsi_lib.c 2008-01-24 14:58:37.000000000 -0800
>> +++ kdb/drivers/scsi/scsi_lib.c 2008-03-19 08:49:19.456568385 -0700
>> @@ -657,13 +657,12 @@ static struct scsi_cmnd *scsi_end_reques
>> /*
>> * If there are blocks left over at the end, set up the command
>> * to queue the remainder of them.
>> + * blk_pc_requests are never requeued.
>> */
>> - if (end_that_request_chunk(req, uptodate, bytes)) {
>> + if (end_that_request_chunk(req, uptodate, bytes) &&
>> + !blk_pc_request(req)) {
>> int leftover = (req->hard_nr_sectors << 9);
>>
>> - if (blk_pc_request(req))
>> - leftover = req->data_len;
>> -
>> /* kill remainder if no retrys */
>> if (!uptodate && blk_noretry_request(req))
>> end_that_request_chunk(req, 0, leftover);
>>
>> Signed-off-by: Michael Reed <mdr@sgi.com>
>
> This will not work. Failing to complete the remaining of the request like that
> will leak BIOs. The upper layer bugs must be fixed. The WARN_ON is good because
> it identifies a bug at upper layer that must be fixed but goes on to
> complete the request. What you could do that will work well is at:
> + WARN_ON(1);
> + good_bytes = req->data_len;
> + goto retry_end_req;
> change that to be:
>
> + WARN_ON(1);
> + good_bytes = ~0;
> + goto retry_end_req;
>
> This will always insure a full complete of the request the second round, but
> will keep the WARN_ON for one time. The patch to scsi_req_map_sg should be applied
> for the stable 2.6.24.x releases, it is a bug.
scsi_end_that_request() doesn't do that for non-block_pc requests. If blk_no_retry_request
is set, it just ends the leftovers. Does that make it subject to the same leaking bio
problem?
Could you just pass ~0 to the call to end_that_request_chunk() instead
of leftover? This would handle the case of other code paths that get
bi_size wrong also. (Granted, this should never happen.)
How 'bout this?
--- a/drivers/scsi/scsi_lib.c 2008-01-24 14:58:37.000000000 -0800
+++ b/drivers/scsi/scsi_lib.c 2008-03-19 14:01:32.637078500 -0700
@@ -657,16 +657,13 @@ static struct scsi_cmnd *scsi_end_reques
/*
* If there are blocks left over at the end, set up the command
* to queue the remainder of them.
+ * blk_pc_requests are never requeued.
*/
if (end_that_request_chunk(req, uptodate, bytes)) {
- int leftover = (req->hard_nr_sectors << 9);
-
- if (blk_pc_request(req))
- leftover = req->data_len;
-
/* kill remainder if no retrys */
- if (!uptodate && blk_noretry_request(req))
- end_that_request_chunk(req, 0, leftover);
+ if ((!uptodate && blk_noretry_request(req)) ||
+ blk_pc_request(req))
+ end_that_request_chunk(req, uptodate, ~0);
else {
if (requeue) {
/*
Mike
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2008-03-19 21:34 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-03-11 22:10 [PATCH] 2.6.25-rc4-git3 - inquiry cmd issued via /dev/sg? device causes infinite loop in 2.6.24 Michael Reed
2008-03-12 10:46 ` Boaz Harrosh
2008-03-12 16:03 ` Michael Reed
2008-03-12 16:09 ` Boaz Harrosh
2008-03-14 13:11 ` Michael Reed
2008-03-18 16:12 ` Michael Reed
2008-03-18 16:20 ` Boaz Harrosh
2008-03-18 16:52 ` Michael Reed
2008-03-18 17:19 ` Boaz Harrosh
2008-03-19 15:57 ` Michael Reed
2008-03-19 16:18 ` Boaz Harrosh
2008-03-19 21:34 ` Michael Reed
2008-03-18 17:13 ` Michael Reed
2008-03-18 18:23 ` Boaz Harrosh
2008-03-18 19:51 ` Michael Reed
2008-03-19 9:49 ` Boaz Harrosh
2008-03-17 18:08 ` Mike Christie
2008-03-18 0:48 ` FUJITA Tomonori
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).