Stack overflow when lldd returns SCSI_MLQUEUE_DEVICE_BUSY

Stack overflow when lldd returns SCSI_MLQUEUE_DEVICE_BUSY

[Heiko Carstens]

Hi all,

I just experienced a stack overflow (see below for part of the call trace)
when an lldd returns SCSI_MLQUEUE_DEVICE_BUSY. Problem seems to be that
scsi_dispatch_cmd calls scsi_queue_insert if the LLDD queuecommand function
failed.

 [<00000000001b0a6a>] zfcp_scsi_queuecommand+0x32/0x44 
 [<0000000000138892>] scsi_dispatch_cmd+0x2ca/0x334 
 [<000000000013f7c8>] scsi_request_fn+0x26c/0x548 
 [<000000000012b2f6>] blk_insert_request+0x126/0x140 
 [<000000000013e1e6>] scsi_queue_insert+0xa6/0xd8 
 [<0000000000138856>] scsi_dispatch_cmd+0x28e/0x334 
 [<000000000013f7c8>] scsi_request_fn+0x26c/0x548 
 [<000000000012b2f6>] blk_insert_request+0x126/0x140 
 [<000000000013e1e6>] scsi_queue_insert+0xa6/0xd8 
 [<0000000000138856>] scsi_dispatch_cmd+0x28e/0x334 
 [<000000000013f7c8>] scsi_request_fn+0x26c/0x548 
 [<000000000012b2f6>] blk_insert_request+0x126/0x140 
 [<000000000013e1e6>] scsi_queue_insert+0xa6/0xd8 
 [<0000000000138856>] scsi_dispatch_cmd+0x28e/0x334 
 [<000000000013f7c8>] scsi_request_fn+0x26c/0x548 
 [<000000000012b2f6>] blk_insert_request+0x126/0x140 
 [<000000000013e12e>] scsi_insert_special_req+0x4e/0x60 
 [<000000000013e2a0>] scsi_do_req+0x88/0x98 
 [<000000000013e3e6>] scsi_wait_req+0x7a/0xdc 
 [<00000000001408ae>] scsi_probe_lun+0x92/0x2f8 
 [<000000000014110a>] scsi_probe_and_add_lun+0xaa/0x290 
 [<00000000001414c2>] scsi_add_device+0x6e/0xc4 
 [<00000000001b529e>] zfcp_erp_scsi_add_device+0x46/0xc4
 [<000000000003c614>] worker_thread+0x1fc/0x2ac 
 [<0000000000041854>] kthread+0xe4/0xec 
 [<0000000000019c00>] kernel_thread_starter+0x14/0x1c 

This is 2.6.6 btw.
Heiko

Re: Stack overflow when lldd returns SCSI_MLQUEUE_DEVICE_BUSY

[James Bottomley]

On Mon, 2004-05-17 at 08:23, Heiko Carstens wrote:
> Hi all,
> 
> I just experienced a stack overflow (see below for part of the call trace)
> when an lldd returns SCSI_MLQUEUE_DEVICE_BUSY. Problem seems to be that
> scsi_dispatch_cmd calls scsi_queue_insert if the LLDD queuecommand function
> failed.
> 
>  [<00000000001b0a6a>] zfcp_scsi_queuecommand+0x32/0x44 
>  [<0000000000138892>] scsi_dispatch_cmd+0x2ca/0x334 
>  [<000000000013f7c8>] scsi_request_fn+0x26c/0x548 
>  [<000000000012b2f6>] blk_insert_request+0x126/0x140 
>  [<000000000013e1e6>] scsi_queue_insert+0xa6/0xd8 
>  [<0000000000138856>] scsi_dispatch_cmd+0x28e/0x334 
>  [<000000000013f7c8>] scsi_request_fn+0x26c/0x548 
>  [<000000000012b2f6>] blk_insert_request+0x126/0x140 
>  [<000000000013e1e6>] scsi_queue_insert+0xa6/0xd8 
>  [<0000000000138856>] scsi_dispatch_cmd+0x28e/0x334 
>  [<000000000013f7c8>] scsi_request_fn+0x26c/0x548 
>  [<000000000012b2f6>] blk_insert_request+0x126/0x140 
>  [<000000000013e1e6>] scsi_queue_insert+0xa6/0xd8 
>  [<0000000000138856>] scsi_dispatch_cmd+0x28e/0x334 
>  [<000000000013f7c8>] scsi_request_fn+0x26c/0x548 
>  [<000000000012b2f6>] blk_insert_request+0x126/0x140 
>  [<000000000013e12e>] scsi_insert_special_req+0x4e/0x60 
>  [<000000000013e2a0>] scsi_do_req+0x88/0x98 
>  [<000000000013e3e6>] scsi_wait_req+0x7a/0xdc 
>  [<00000000001408ae>] scsi_probe_lun+0x92/0x2f8 
>  [<000000000014110a>] scsi_probe_and_add_lun+0xaa/0x290 
>  [<00000000001414c2>] scsi_add_device+0x6e/0xc4 
>  [<00000000001b529e>] zfcp_erp_scsi_add_device+0x46/0xc4
>  [<000000000003c614>] worker_thread+0x1fc/0x2ac 
>  [<0000000000041854>] kthread+0xe4/0xec 
>  [<0000000000019c00>] kernel_thread_starter+0x14/0x1c 

Could you do some more debugging...there's something wierd going on
here.  a SCSI_MLQUEUE_DEVICE_BUSY return sets device_blocked.  As long
as sdev->max_device_blocked is two or more, this should cause an exit
from the next scsi_request_fn() (at the if(!req ||
!scsi_dev_queue_ready(q, sdev))

James

Re: Stack overflow when lldd returns SCSI_MLQUEUE_DEVICE_BUSY

[Heiko Carstens]

> > I just experienced a stack overflow (see below for part of the call 
trace)
> > when an lldd returns SCSI_MLQUEUE_DEVICE_BUSY. Problem seems to be 
that
> > scsi_dispatch_cmd calls scsi_queue_insert if the LLDD queuecommand 
function
> > failed.
>
> Could you do some more debugging...there's something wierd going on
> here.  a SCSI_MLQUEUE_DEVICE_BUSY return sets device_blocked.  As long
> as sdev->max_device_blocked is two or more, this should cause an exit
> from the next scsi_request_fn() (at the if(!req ||
> !scsi_dev_queue_ready(q, sdev))

This happened when sending out the inquiry command and the LLDD was in
recovery for the specific LUN and returned SCSI_MLQUEUE_DEVICE_BUSY.
Problem is that max_device_blocked gets set _after_ the inquiry command
finished. In this specific case max_device_blocked was 0 and thus the
device was never blocked resulting in the observed stack overflow.
I moved the initializazion of max_device_blocked from scsi_add_lun to
sdev_alloc_sdev and the problem is gone. See patch below.
Thanks for pointing out where to look at!

diff -u -r1.44 scsi_scan.c
--- scsi_scan.c 10 May 2004 09:21:32 -0000      1.44
+++ scsi_scan.c 19 May 2004 14:54:19 -0000
@@ -212,6 +212,10 @@
        INIT_LIST_HEAD(&sdev->starved_entry);
        spin_lock_init(&sdev->list_lock);
 
+       /* if the device needs this changing, it may do so in the detect
+        * function */
+       sdev->max_device_blocked = SCSI_DEFAULT_DEVICE_BLOCKED;
+
        /*
         * Some low level driver could use device->type
         */
@@ -626,10 +630,6 @@
                sdev->sdev_target = starget;
                spin_unlock_irqrestore(sdev->host->host_lock, flags);
        }
-
-       /* if the device needs this changing, it may do so in the detect
-        * function */
-       sdev->max_device_blocked = SCSI_DEFAULT_DEVICE_BLOCKED;
 
        sdev->use_10_for_rw = 1;